ubernetes = 


- 


he 


ky 


NX JAR TH "ü 


ST = qn A 


~.. 


ES a See dm 
从 Docker 到 Kubernetes 
实践 全 接触 


> 


— uw 


Js € 


ng (2276877 


T «tici cc 


^ 
t€ 
3 
i 
* 
£ 
4 
i. 
š 


Kubemetes3= by 


Kubernetes EE]: 从 Docker 到 Kubernetes 实 践 全 接 第 2 


www.broa 


dview.com.ca 


1 Kubernetes 


| v 
/ SES 著 / v 


I = Ree mbH a 


$$: sd 
[rr] 中 国 工作 HB 版 人 四 CREE IET. 


| 


图 书 在 版 编目 (CIP) 数据 

Kubernetes 实 战 / 吴 龙 辉 昔 .一 北京 : 电子 工业 出 版 社 ，2016.5 
ISBN 978-7-121-28372-7 

LOK... LOR... 川 .DOLinux 操 作 系 统一 程序 设计 IV. OTP316.85 
中 国 版 本 图 书馆 CIP 数 据 核 字 (2016) 第 055126 号 

策划 编辑 ， 张 春雨 

责任 编辑 : 刘 AA 

FJ — d: 北京 中 新 伟业 印刷 有 限 公司 

A 订 : 北京 中 新 伟业 印刷 有 限 公司 

出 版 发 行 : 电子 工业 出 版 社 


北京 市 海淀 区 万 寿 路 173 信 箱 ”邮编 : 100036 

JT | 本: 787x980 1/6 印张 17.75 FR: 355 千 字 
版 ” 次 : 2016 年 5 月 第 1 版 

EF] 次 : 2016 年 5 月 第 1 次 印刷 

^E M 69.00 元 


凡 所 购买 电子 工业 出 版 社 图 书 有 缺损 问题 ， 请 向 购买 书店 调换 。 阁 书 
店 售 缺 ， 请 与 本 社 发 行 部 联系 ， 联 系 及 邮购 电话 : (010) 88254888 » 


质量 投诉 请 发 邮件 至 zlts@phei.com.cn ， 盗 版 侵权 举报 请 发 邮件 至 
dbqq@phei.com.cn ° 


服务 热线 : (010) 88258888 ° 
未 经 许可 ， 不 得 以 任何 方式 复制 或 抄袭 本 书 之 部 分 或 全 部 内 容 。 
版 权 所 有 ， 侵 权 必 究 。 


内 容 简介 
Ae 

第 1 部 分 Kubernetes 基 础 篇 

第 1 章 Kubernetes 介 绍 

1.1 为 什么 会 有 Kubernetes 

1.2 Kubernetes zT 7 

1.3 Kubernetes 的 发 展 历史 
1.4Kubernetes 的 核心 概念 
2823€ Kubernetes 的 架构 和 部 署 
2.1 Kubernetes 的 架构 和 组 件 
2.2 部 署 Kubernetes 


2.3 安装 Kubernetes: 


第 3 章 Kubernetes 快 速 入 | 
3.1 示例 应用 Guestbook 
3.2 准备 工 


— A— 


3.3 运行 Redis 
3.4 运行 Frontend 


第 4 章 Pod 

4.1 国际 惯例 的 Hello World 
4.2 Pod 的 基本 操作 

4.3 Pod 与 容器 

4.4 Pod 的 网 络 


10.3 Service Account 


10.4 容器 安全 


11.4 Resource Quota 


第 12 章 管理 和 运 维 Kubernetes 


12.4 平台 日 志 
12.5 垃 圾 清理 


12.6 Kubernetes 的 Web 界 HI 


第 13 章 CoreOS 
13.1 CoreOS 介 绍 


ore 
第 14 音 Etcd 
14.1 Ftcd 介 绍 
14.2 Ftcd 的 结构 
14.3 Ftcd 实 践 
第 15 革 Mesos 
15.1 Mesos 介 绍 


15.2 Mesas] 


AAS ial It 


Docker 的 流行 激活 了 一 直 不 温 不 火 的 PaaS， 随 之 而 来 的 是 各 类 
Micro-PaaS 的 出 现 ，Kubermmetes 是 其 中 最 具 代 表 性 的 一 员 ， 它 是 Google 
多 年 大 规模 容器 管理 技术 的 开源 版 本 。 越 来 越 多 的 企业 被 迫 面 对 互联 
网 规模 所 带 来 的 各 类 难题 ， 而 Kubernetes 以 其 优秀 的 理念 和 设计 正在 
逐步 形成 新 的 技术 标准 ， 对 于 任何 领域 的 运营 总 监 、 架 构 师 和 软件 工 
程 师 来 说 ， 都 是 一 个 绝 佳 的 突破 机 会 。 本 书 以 理论 加 实战 的 模式 ， 结 
合 大 量 案 例 由 浅 入 深 地 讲解 了 Kubernetes 的 各 个 方面 ， 包 括 平 台 染 
构 、 基 础 核心 功能 、 网 络 、 安 全 和 资源 管理 以 及 整个 生态 系统 的 组 
成 ， 引 在 帮助 读者 全 面 深入 地 掌握 Kubernetes+Docker 的 底层 技术 挫 
栈 。 
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随 着 互联 网 技术 在 各 领域 的 广泛 应 用 ， 所 产生 的 海量 数据 催生 了 
大 数据 的 诞生 。 而 对 于 数据 中 心 的 需求 激活 了 云 计 算 井 喷 式 的 发 展 ， 
一 时 间 大 数据 和 云 计 算 成 为 各 个 企业 争夺 的 战略 高 地 。 


在 云 计算 领域 的 服务 模式 中 ，IaaS 和 SaaSs 模 式 已 经 趋 于 成 熟 ， 
此 PaaS 惑 成 了 全 球 各 大 IT 巨头 和 初创 公司 的 焦点 ， 其 中 的 竞争 异常 激 
烈 。 大 量 鸣 PaaSs 平 台 出 现 ， 又 很 快 被 淘汰 ， 整 个 行业 发 生 着 巨大 的 友 
代 更 奉 。 正 所 谓 物 竞 天 择 ， 在 这 样 一 个 激荡 变化 的 背景 下 ， 以 Docker 
为 代表 的 容 髓 技术 脱颖而出 并 极速 发 热 ， 风 头 无 两 ， 大 多 数 主 流 云 矿 
商 已 经 宣布 提供 对 Docker 及 其 生态 系统 的 文 持 。 容 器 技术 具备 融合 
DevOps 的 敏捷 特性 ， 给 云 计算 市 场 特别 是 PaaS 市 场 市 来 了 新 的 变革 力 
量 ，Kubemetes 就 是 狐 一 轮 变 革 中 产生 的 一 个 代表 性 产品 。 


Kubernetes 是 Google 开 源 的 容 絮 集群 管理 系统 ， 它 对 于 容 颖 运行 
上 时、 编排、 常规 服务 都 抽象 设计 出 了 准确 完整 的 API， 并 以 此 建立 起 
一 个 开放 开源 的 系统 ， 符 合 企业 化 需求 ， 每 家 企业 都 可 以 以 此 搭建 出 
和 目 动 化 和 标准 化 的 底层 平台 ， 以 优化 研发 和 运营 效率 。Kubernetes 可 
以 说 是 Google 借 助 着 容 句 领域 的 爆发 ， 对 于 其 巨大 规模 数据 中 心 管理 
的 丰富 经 验 的 一 次 实践 ， 旨 在 建立 新 的 技术 业界 标准 。 


展望 未 来 ， 我 们 认为 将 有 更 多 的 企业 被 迫 面 对 互联 网 规模 所 吝 来 
的 各 类 难题 ，Kubernetes 和 Docker 技 术 可 以 提供 应 对 这 些 挑 战 的 解决 方 
案 。 而 随 着 更 多 企业 的 加 入 ， 会 有 更 多 的 人 以 协作 方式 构建 出 更 强大 


的 技术 堆栈 和 更 多 的 创新 成 末 ， 整 个 行业 将 朝 着 更 好 的 方 同 持续 过 
进 ， 对 此 我 们 乐观 其 成 。 
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Kubermnetes 的 各 个 方面 ， 包 括 平 台 架 构 、 基 础 核心 功能 、 网 络 、 安 全 
和 资源 管理 ， 以 及 整个 生态 系统 的 组 成 。 技 术 信 息 完 全 来 源 于 
Kubernetes 开 源 社 区 的 文档 、 人 代码 的 提炼 和 总 结 。 本 书 涉 及 的 
Kubermnetes 内 容 与 官方 最 新 版 本 同步 ， 包 含 最 新 版 本 的 所 有 新 特性 说 
明 ， 并 且 因 为 Kubernetes 同 Docker 深 度 集成 ， 所 以 本 书 也 会 前 述 Docker 
相关 的 技术 话题 。 


本 书 的 读者 对 象 


本 书 适用 于 希望 学 习 和 使 用 Kubernetes 以 及 正在 寻找 管理 数据 中 
心 解决 方案 的 软件 工程 师 和 架构 师 ， 同 时 本 书 可 以 作为 Docker 的 高 级 
延伸 书籍 ， 用 于 搭建 基于 KubernetestDocker 的 PaaS 平 台 ， 实 践 
DevOps ° 


本 书 的 组 织 结构 


本 书 在 组 织 结构 上 分 成 三 部 分 : Kubernetes 基 础 篇 、Kubernetes 高 
级 篇 和 Kubernetes 生 态 篇 。 基 础 篇 可 帮助 读者 认识 Kubernetes， 并 理解 
其 架构 和 核心 概念 ， 同 时 能 够 部 署 和 使 用 Kubernetes 完 成 基本 功能 操 
作 。 高 级 篇 将 深入 讲解 Kubernetes 的 网 络 、 安 全 和 资源 管理 等 话题 ， 
帮助 读者 掌握 管理 Kubernetes 的 能 力 。 生 态 篇 则 介绍 与 Kubernetes 密 切 


相关 的 开源 软件 ， 包 括 CoreOS、Etcd 和 Mesos， 使 读者 对 于 Kubernetes 
生态 系统 有 全 面 的 了 解 。 
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第 1 章 
Kubernetes 介 绍 


Kubernetes 可 以 说 是 云 计 算 PaaS 领 域 的 集大成 者 ， 它 借助 了 最 好 
的 帮助 ， 并 旦 在 最 适当 的 时 间 推 出 ， 从 而 得 到 了 最 多 的 天 注 。 本 半 首 
先 从 整个 行业 背景 介绍 入 手 ， 介 绍 Kubernetes 诞 生 的 前 因 ， 并 阐述 
Kubernetes 的 优势 和 发 展 历程 ， 最 后 说 明 Kubernetes 中 的 基本 概念 ， 帮 
助 读者 对 Kubernetes 有 一 个 初步 但 全 面 的 认识 。 


1.1 为 什么 会 有 Kubernetes 


1.1.1 云 计算 大 湖 


云 计算 (Cloud Computing) 作为 一 个 新 兴 领 域 ,， 它 是 多 种 技术 混 
合演 进 的 结 采 ， 在 许多 大 公司 和 初创 企业 的 共同 推动 下 ， 发 展 极 为 迅 
速 并 且 持 续 火 热 ， 带 来 了 新 一 轮 的 开 变 革 。 云 计算 带 给 企业 的 创新 能 
力 和 发 展 空间 是 不 可 想象 的 ， 我 们 所 有 人 部 正 处 于 云 计算 大 淹 中 。 


云 计算 从 狭义 上 讲 ， 指 IT 基 础 设施 的 交付 和 使 用 模式 ， 即 通过 网 
络 以 按 需 、 易 扩展 的 方式 获取 所 需 资 源 。 广 义 上 则 指 服务 的 交付 和 使 
用 模式 ， 通 过 网 络 以 按 需 、 易 扩展 的 方式 获取 所 需 服 务 。 提 供 资源 的 
网 络 被 形象 地 比喻 成 “< 云 "， 其 计算 能 力 通 第 是 由 分 布 式 的 大 规模 集群 


和 虚拟 化 技术 提供 的 。 而 “ 云 ” 中 的 计算 货源 在 用 户 看 来 是 可 以 扩展 ， 
并 且 可 以 随时 获取 、 按 需 使 用 的 。 


云 计 算 彻 搬 改变 了 人 们 对 计算 资源 的 使 用 方式 ， 有 一 个 形象 的 比 
喻 说 明了 云 计算 革命 性 的 影响 :“ 云 ”好 比 一 个 发 电厂 ， 互 联网 好 比 是 
输电 线路 ， 只 不 过 这 个 发 电厂 对 外 提供 的 是 IT 服 务 ， 这 种 服务 将 通过 
互联 网 传输 到 千家 万 户 。 云 计算 实现 了 计算 资源 从 单 台 发 电机 供电 模 
式 同 电厂 集中 供电 模式 的 转变 。 


业界 根据 云 计算 提供 服务 资源 的 类 型 将 其 划分 为 三 大 类 : 基础 设 
施 即 服务 (Infrastructure-as-a-Service, IaaS) 、 平 台 即 服务 (Platform- 
as-a-Service, Paas) 和 软件 即 服务 (Software-as-a-Service，SaaS) ， 
如 图 1-1 所 示 。 
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图 1-1 云 计 算 的 三 层 架构 


- 基础 设施 即 服务 


基础 设施 即 服务 (laas) 通过 虚拟 化 和 分 布 式 存 储 等 技术 ， 实 现 
了 对 包括 服务 絮 、 存 储 设备 、 网 络 设备 等 各 种 物理 资源 的 抽象 ， 从 而 
形成 了 一 个 可 扩展 、 可 按 需 分 配 的 虚拟 资源 池 。IaaSs 对 外 呈现 的 服务 
是 各 种 基础 设置 ， 例 如 虚拟 机 、 磁 强 以 及 主机 互联 而 成 的 网 络 ， 这 些 
虚拟 机 中 可 以 运行 Windows 系 统 ， 也 可 以 运行 Linux 系 统 ， 在 用 户 看 
来 ， 它 与 一 台 真 实 的 物理 机 是 没有 区 别 的 。 目 前 最 具 代 表 性 的 Iaas 产 
品 有 Amazon AWS， 其 提供 了 虚拟 机 EC2 和 云 存储 S3 等 服务 。 


“平台 即 服务 


平台 即 服 务 (PaaS) 为 开发 者 提供 了 应 用 的 开发 环境 和 运行 环 
境 ， 将 开发 者 从 烦琐 的 IT 环境 管理 中 解放 出 来 。 目 动 化 应 用 的 部 署 和 
运 维 ， 使 开发 者 能 够 集中 精力 于 应 用 业务 开发 ， 极 大 地 提升 了 应 用 的 
开发 效率 。 可 以 说 ，PaaS 主 要 面 同 的 是 软件 专业 人 员 ，Google 的 GAE 
是 PaaS 的 蜡 祖 ， 而 Kubemetes 可 以 说 是 在 PaaS 的 定义 范畴 内 。 


。 软件 即 服 务 


软件 即 服务 (SaaS) 主要 面向 使 用 软件 的 终端 用 户 。 一 般 来 说 ， 
SaaS 将 软件 功能 以 特定 的 接口 形式 发 布 ， 终端 用 户 通 过 网 络 浏览 紫 束 
可 以 使 用 软件 功能 。 终 端 用 户 将 只 关注 软件 业务 的 使 用 ， 除 此 之 外 的 
工作 ， 如 软件 的 升级 和 云端 实现 ， 对 终端 用 户 来 说 都 是 透明 的 。SaaS 


征 应 用 最 广 的 云 计 算 模 式 ， 比 如 我 们 在 线 使 用 的 邮箱 系统 和 各 种 管理 
系统 都 可 以 认为 是 SaaS 的 范畴 。 


综 上 所 述 ， 可 以 简单 地 概括 为 : SaaS 通 过 网 络 运 行 ， 为 最 终 用 户 
提供 应 用 服务 ，PaaSs 坪 一 套 工具 服务 ， 可 以 为 编码 和 部 署 应 用 程序 拓 
供 快速 、 高 效 的 服务 ，IaaS 包 括 人 硬件 和 软件 ， 例 如 服务 上 器、 存储、 网 
络 和 操作 系统 。 


与 SaaS 相 比 ，PaaS 和 IaaS 的 概念 和 技术 相对 较 新 ， 图 1-2 比 较 了 传 
统 IT、IaaS 和 PaaSs。 假 设 现在 要 上 线 一 项 新 业务 ， 传 统 IT 的 做 法 就 是 
自 下 而 上 地 搭建 部 署 、 购 置 硬件 、 配 置 网 络 、 安 装 操作 系统 、 部 署 中 
间 件 系统 ， 到 最 后 业务 上 线 。 使 用 Iaas 的 客户 则 无 须 关 心 操 作 系 统 以 
下 的 实现 ，Paas 更 进一步 封装 操作 系统 、 中 间 件 和 运行 时 ， 形 成 标准 
式 的 业务 发 布 平 台 ， 提 供 智 能 化 运 维 能 力 。 这 是 一 种 递 进 式 的 演化 ， 


一 步 一 步 地 将 技术 栈 分 层 分 级 ， 将 资源 进行 整合 管理 ， 可 极 大 提高 效 
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图 1-2 传统 IT、IaaS 和 PaaS 的 比较 


正 古 由 于 云 计算 的 强大 优势 ， 越 来 越 多 的 公司 进入 这 波 潮流 中 ， 
形成 了 百 家 齐 放 的 场面 。 在 云 计算 的 不 同 层 次 ， 在 各 个 行业 的 不 同 领 
域 ， 都 涌现 出 一 大 批 云 计 算 产 品 ， 整 个 云 计算 市 场 正在 高 速 发 展 。 


1.1.2 不 温 不 火 的 PaaS 


在 SaaS 的 成 熟 和 IaaS 的 高 速 发 展 催生 下 ， 特 别 是 在 Amazon ^ 
Google、Salesforce、Microsoft 等 公司 的 推动 下 ，PaaS 得 到 了 长 足 的 发 
展 ， 越 来 越 多 的 人 开始 谈论 和 关注 PaaS， 包 括 运 营 商 、 互 联网 巨头 、 
传统 IT 厂商 、 咨 询 和 集成 商 、IT 技 术 媒体 等 。 但 是 PaaS 的 发 展 可 以 说 
是 一 波 三 折 ， 可 以 分 为 三 个 阶段 。 


。 第 一 代 Paas 


比如 GAE (Google App Engine) ^ SAE (Sina App Engine) 。 这 
ve FHA PaaS, SHA PaaS hia, UTE A Re HB EPs 
围 内 的 。 


。 第 二 代 PaaS 


比如 Cloud Foundry ` Openshift ° 这 是 各 大 Iaas (如 Amazon 
AWS ` OpenStack) 流行 之 后 ， 顺 势 推 出 的 PaaSs， 并 且 发 展 迅 速 。 其 中 
Cloud Foundry 是 VMware 于 2011 年 推出 的 业界 第 一 个 开源 PaaSs 云 平 
台 ， 后 来 分 拆 出 Pivotal 公 司 进行 接管 ，2014 创 立 Cloud Foundry 基 金 会 
进行 运作 。 技 术 和 模式 相 比 第 一 代 PaaS 都 有 一 定 的 提高 ， 在 云 计 算 大 
潮 中 引领 了 了 PaaS 的 发 展 ， 一 时 成 为 PaaS 的 代表 。 华 为 云 、IBM 
BlueMix、HP Cloud 和 Dell 云 服务 都 采用 了 Cloud Foundry 作 为 基础 。 


但 是 这 个 阶段 的 PaaS 不 管 是 在 市 场 份额 ， 还 是 提升 速度 上 都 处 于 
弱势 ， 用 户 对 PaaS 的 兴趣 似乎 也 不 大 。 同 时 ， 随 着 各 种 云 服务 之 间 界 
限 的 逐步 模糊 ， 一 部 分 人 其 至 认为 PaaS 将 最 终 消亡 或 成 为 18aS 或 者 
SaaS 的 一 个 功能 ，PaaS 处 于 不 温 不 火 的 尴 认 位置。 


。 第 三 代 PaaS 


在 Docker 火 爆 之 后 ， 利 用 Docker 的 特性 构建 出 许多 PaaS， 比 如 
Kubernetes。 这 些 PaaS 更 加 灵活 ， 更 加 适应 企业 ， 了 逐渐 成 为 PaaS 的 主 
力 o 


1.1.3 Docker č% 


Docker 是 一 种 Linux 容 器 工具 集 ， 它 是 为 构建 (Build) ^ XIT 
(Ship) 和 运行 (Run) 分 布 式 应 用 而 设计 的 。 作 为 DotCloud 公 司 的 开 
源 项 目 ， 其 首发 版 本 的 时 间 是 2013 年 3 月 。 该 项 目 很 快 就 受到 欢迎 ， 这 
也 使 得 DotCloud 公 司 将 其 品牌 改 为 Docker， 并 最 终 将 其 原 有 的 PaaS 业 
务 出 售 而 专注 在 Docker 上 ，Docker 完 成 了 华丽 的 逆 袭 。 


Docker 设 计 理 论 来 自 集装箱 ， 假 设 交付 运行 环境 如 同 海 运 ， 操 作 
系统 如 同一 艘 货轮 ， 每 一 个 在 操作 系统 基础 上 运行 的 软件 都 如 同一 个 
集 狐 箱 ， 用 户 可 以 通过 标准 化 手段 目 由 组 洲 运 行 环境 ， 同 时 集 北 箱 的 
内 容 可 以 由 用 户 目 定义 ， 也 可 以 由 专业 人 员 制 造 。 这 样 ， 交 付 一 个 软 
件 ， 束 古 一 系列 标准 化 组 件 的 集合 的 交付 ， 如 同 搭建 乐高 积木 ， 用户 


只 需 选 择 合 适 的 积木 组 合 ， 并 且 在 顶端 车 上 目 己 的 名 字 ， 最 后 这 个 标 
准 化 组 件 就 是 用 户 的 应 用 。 


基于 这 个 理念 ， 在 技术 实现 上 ，Docker 利 用 容器 (Container) 来 
实现 类 似 虚 拟 机 的 功能 ， 从 而 利用 更 加 节省 的 硬件 资源 提供 给 用 户 更 
多 的 计算 资源 。 同 虚拟 机 的 方式 不 同 ， 容 大 并 不 是 一 套 硬 件 虚 拟 化 方 
法 ， 也 无 法 归属 到 全 虚拟 化 、 部 分 虚拟 化 和 半 虚 拟 化 中 的 任意 一 个 ， 
而 是 一 个 操作 系统 级 虚拟 化 方法 。 


Docker 容 器 技术 的 优势 有 以 下 几 点 。 
© 一 次 构建 ， 到 处 运行 


当 将 容器 固化 成 镜像 后 ， 可 以 快速 地 加 载 到 任何 环境 中 部 署 
运行 。 而 构建 出 来 的 镜像 打包 了 应 用 运行 所 需 的 程序 、 依 赖 和 运 
行 环境 ， 这 有 是 一 个 完整 可 用 的 应 用 集 逆 箱 ， 在 任何 环境 下 都 能 保 
证 环境 的 一 致 性 。 


* 容器 的 快速 轻 量 
容器 的 启动 、 停 止 和 销毁 都 是 以 秒 或 毫秒 为 单位 的 ， 并 且 相 


比 传统 的 虚拟 化 技术 ， 使 用 容器 在 CPU、 内 存 ， 网 络 IO 等 资源 上 
的 性 能 损耗 都 有 同样 水 平 甚至 更 优 的 表现 。 


“完整 的 生态 链 


容器 技术 并 不 是 Docker 首 创 ， 但 是 以 往 的 容器 实现 只 关注 于 
如 何 运 行 ， 而 Docker 丫 在 巨人 的 肩膀 上 进行 了 整合 和 创新 ， 特 别 
征 Docker 镜 像 的 设计 ， 完 美 地 为 容 船 从 构建 、 区 付 到 运行 提供 了 
完整 的 生态 链 文 持 。 


Docker 1.0 在 2014 年 6 月 发 布 ， 而 且 延 续 了 之 前 每 月 发 布 一 个 版 本 
的 节奏 。 其 1.0 版 本 标志 着 Docker 公 司 认为 Docker 平 台 已 经 足够 成 熟 ， 
并 可 以 被 应 用 到 生产 环境 中 。 每 月 的 版 本 更 新 显示 出 该 项 目 正在 快速 
发 展 ， 比 如 增加 新 的 特性 ， 解 决 发 现 的 问题 等 。 


Docker 的 持续 火热 是 有 着 坚实 的 基础 来 支撑 的 。Docker 吸 引 了 业 
界 从 多 知名 大 脾 厂 XWX, HF A f Amazon ^ Canonical ^ 
CenturyLink ` Google ` IBM ^ Microsoft ` New Relic ` Pivotal ` Red Hat 
和 VMware， 这 使 得 只 要 在 有 Linux 的 地 方 ，Docker 就 儿 乎 随处 可 用 。 
除了 这 些 大 三 ， 许 多 初创 企业 也 围绕 着 Docker 来 发 展 ， 或 是 将 他 们 的 
发 展 方 喇 和 Docker 更 好 地 结合 起 来 。 所 有 这 些 合作 伙伴 都 驱动 着 
Docker 核 心 项 目 和 周边 生态 系统 的 快速 发 展 。 


更 重要 的 是 Docker 的 流行 和 标准 化 ， 激 活 了 一 直 不 温 不 火 的 
PaaS， 随 之 而 来 的 是 各 类 Micro-PaaS 的 出 现 ，Kubemetes 是 其 中 最 具 代 
表 性 的 一 员 。 


1.2 Kubernetes 是 什么 


Kubernetes 是 Google 开 源 的 容器 集群 管理 系统 。 它 构建 在 Docker 技 
术 之 上 ， 为 容器 化 的 应 用 提供 资源 调度 、 部 署 运行 、 服 务 发 现 、 扩 容 


Yaa SMB R, At La Ae ea T R as FX WY Micro-PaaS E 
f, 即 第 三 代 paas 的 代表 性 项 目 。 


Google 从 2004 年 起 就 已 经 开始 使 用 容器 技术 了 ， 于 2006 年 发 布 了 
Cgroup， 而 且 内 部 开发 了 强大 的 集群 资源 管理 平台 Borg 和 Omega， 这 
些 都 已 经 广泛 使 用 在 Google 的 各 个 基础 设施 中 ， 而 Kubernetes 的 灵感 来 
更 是 吸收 了 包括 Omega 在 内 的 容 絮 管理 

妖 的 经 验 和 教训 | 。 


Kubernetes, t Æ SRB EAE FIR, th Æ Cyber HY id 15 , 
Kubernetes 利 用 Google 在 容器 技术 上 的 实践 经 验 和 技术 积 LA, FREY HY 
Docker 社 区 的 最 佳 实践 ， 已 经 成 为 云 计 算 服 务 的 舵手 。 


Kubernetes 有 着 如 下 的 优秀 特性 9 


* 强大 的 容器 编排 能 力 


Kubernetes 可 以 说 是 同 Docker 一 起 发 展 起 来 的 ， 深 度 集 成 了 
Docker， 天 然 适 应 容器 的 特点 ， 设 计 出 强大 的 容器 编排 能 力 ， 比 
如 容 絮 组 合 、 标 签 选 择 和 服务 发 现 等 ， 可 以 满足 企业 级 需求 。 


* 轻 量 级 


Kubernetes 遵 循 微 服务 架构 理论 ， 整 个 系统 划分 出 各 个 功能 
独立 的 组 件 ， 组 件 之 间 边 界 清晰 ， 部 署 简单 ， 可 以 轻易 地 运行 在 


各 种 系统 和 环境 中 。 同 时 ，Kubernetes 中 的 许多 功能 都 实现 了 插 
件 化 ， 可 以 非 背 方便 地 进行 扩展 和 替换 。 


* 开放 开源 


Kubernetes 顺 应 了 开放 开源 的 趋势 ， 吸 引 了 大 批 开 发 者 和 公 
司 参与 其 中 ， 协 同 工 作 共同 构建 生态 轿 。 同 时 ，Kubernetes 同 
OpenStack、Docker 等 开源 社区 积极 合作 、 共 同 发 展 ， 企 业 和 个 人 
都 可 以 参与 其 中 并 获 益 。 


1.3 ”Kubernetes 的 发 展 历史 


Kubernetes 目 推出 后 迅速 得 到 关注 和 参与 ，2015 年 7 月 经 过 400 多 
位 页 献 者 一 年 的 努力 ， 多 达 14,000 次 代码 提交 ，Google 正 式 对 外 发 布 
T Kubernetes v1.0， 意 味 着 这 个 开源 容器 编排 系统 可 以 正式 在 生产 环 
境 中 使 用 。 与 此 同时 ， 合 歌 联 合 Linux 基 金 会 及 其 他 合作 伙伴 共同 成 立 
了 CNCF 基金 会 (Cloud Native Computing Foundation) ， 并 将 
Kubernetes 作 为 站 个 编 入 CNCF 基 金 会 管理 体系 的 开源 项 目 ， 助 力 容 妖 
技术 生态 的 发 展 进步 。 


Kubernetes 的 发 展 里 程 碑 如 下 所 示 。 
。2014 年 6 月 : 谷歌 宣布 Kubernetes 开 源 。 


。2014 年 7 月 : Microsoft ^ Red Hat ` IBM ` Docker ` CoreOS ` 
Mesosphere#ll Saltstack JI] ^ Kubernetes ° 


* 2014448: Mesosphere 宣 布 将 Kubernetes 作 为 框架 整合 到 
Mesosphere 生 态 系统 中 ， 用 于 Docker 容 髓 集群 的 调度 、 部 署 和 管理 。 


。2014 年 8 月 : VMware 加 入 Kubernetes 社 区 ，Google 产 品 经 理 Craig 
Mcluckie 公 开 表 示 ，VMware 将 会 帮助 Kubernetes 实 现 利 用 虚拟 化 来 保 
证 物理 主机 安全 的 功能 模式 。 


。2014 年 11 月 : HP 加 入 Kubernetes 社 区 。 


。2014 年 11 月 : Google 容 器 引 敬 Alpha 启动 ， 谷 歌 宣 布 GCE 文 持 容 
句 及 服务 ， 并 以 Kubernetes 为 构架 。 


。2015 年 1 月 : Google 和 Mirantis 及 伙伴 将 Kubernetes 引入 
OpenStack， 开 发 者 可 以 在 OpenStack 上 部 署 运行 Kubernetes 应 用 。 


。2015 年 4 月 : Google 和 CoreOS 联 合 发 布 Tectonic， 它 将 Kubernetes 
和 CoreOS 软 件 栈 整 合 在 了 一 起 。 


。2015 年 5 月 : Intel 加 入 Kubernetes 社 区 ， 宣 布 将 合作 加 速 Tectonic 
软件 栈 的 发 展 进度 。 


。2015 年 6 月 : Google 容 器 引 警 进入 beta 版 。 


。2015 年 7 月 : Google 正 式 加 入 OpenStack 基 金 会 ，Kubernetes 产 品 
经 理 Craig McLuckie 宣 布 Google 将 成 为 OpenStack 基 金 会 的 发 起 人 之 
一 ，Google 将 把 他 的 容器 计算 的 专家 技术 带 入 OpenStack， 以 提高 公有 
云 和 私有 云 的 互 用 性 。 


。2015 年 7 月 : Kubernetes v1.0 正 式 发 布 。 


1.4 Kubernetes 的 核心 概念 


1.4.1 Pod 


Pod 是 大 和 干 相关 容 事 的 组 合 ，Pod 包 含 的 容 顺 运行 在 同一 台 和 宿主 机 
上 ， 这 些 容 帮 使 用 相同 的 网 络 命名 空间 、IP 地 址 和 端口 ， 相 互 之 间 能 
通过 localhost 来 发 现 和 通信 。 男 外 ， 这 些 容 磊 还 可 共 至 一 块 存储 卷 空 
间 。 在 Kubernetes 中 创建 、 调 度 和 管理 的 最 小 单位 是 Pod， 而 不 是 容 
名，Pod 通 过 提供 更 高 层次 的 抽象 ， 提 供 了 更 加 灵活 的 部 晋 和 管理 模 
式 。 


1.4.2 Replication Controller 


Replication Controller 用 来 控制 管理 Pod 副 本 (Replica, BLA PRA 
实例 ) , Replication Controller 确 保 任 何 时 候 Kubernetes 集 群 中 有 指定 数 
量 的 Pod 副 本 在 运行 。 如 采 少 于 指定 数量 的 Pod 副 本 Replication 
Controller 会 局 动 新 的 Pod 副 本 ， 反 之 会 杀 死 多 余 的 副本 以 保证 数量 不 
变 。 男 外 ，Replication Controller 是 弹性 伸缩 、 滚 动 升级 的 实现 核心 。 


1.4.3 Service 


Service 是 真实 应 用 服务 的 抽象 ， 定 义 了 Pod 的 逻辑 集合 和 访问 这 
个 Pod 和 集合 的 策略 。Service 将 代理 Pod 对 外 表现 为 一 个 单一 访问 接口 ， 


外 部 不 需要 了 解 后 并 Pod 如 何 运 行 ， 这 给 扩展 和 维护 市 来 很 多 好 处 ， 
提供 了 一 套 人 简化 的 服务 代理 和 发 现 机 制 。 


1.4.4 Label 


Labelzé Hl T [X 47 Pod ` Service ^ Replication Controllerf‘JKey/Value 
对 ， 实 际 上 ，Kubernetes 中 的 任意 API 对 象 都 可 以 通过 Label 进 行 标识 。 
每 个 API 对 象 可 以 有 多 个 Label， 但 是 每 个 Label 的 Key 只 能 对 应 一 个 
Value。Label 是 Service 和 Replication Controller 运 行 的 基础 ， 它 们 都 通过 
Label 来 天 联 Pod， 相 比 于 强 绑 定 模型 ， 这 是 一 种 非常 好 的 松 耦 合 天 
系 o 


1.4.5 Node 


Kubernetes 属 于 主 从 分 布 式 集群 架构 ，Kubernetes Node (简称 为 
Node， 早 期 版 本 叫 作 Minion) 运行 并 管理 容器 。Node 作 为 Kubernetes 
的 操作 单元 ， 用 来 分 配给 Pod (或 者 说 容器 ) 进行 绑 定 ，Pod 最 终 运 行 
在 Node 上 ，Node 可 以 认为 是 Pod 的 答 主 机 。 


75238. 
Kubernetes 的 架构 和 部 署 


Kubernetes 亲 人 循 微服 务 染 构 理 论 ， 整 个 系统 划分 出 各 个 功能 独立 
的 组 件 ， 组 件 之 间 边 界 清晰 ， 部 署 简单 ， 可 以 轻易 地 运行 在 各 种 系统 
和 环境 中 。 本 章 将 首先 介绍 Kubernetes 的 架构 和 各 个 组 件 的 功能 ， 然 
后 详细 说 明 如 何 从 头 开始 部 署 一 套 完整 的 Kubernetes 运 行 环境 ， 包 括 
Kubernetes 提 供 的 各 种 扩展 插件 (Cluster Add-on) 的 安装 方式 。 


2.1 ”Kubernetes 的 架构 和 组 件 


Kubernetes 属 于 主 从 分 布 式 架 构 ， 廊 点 在 角色 上 分 为 Master 和 
Node， 如 图 2-1 所 示 。 
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图 2-1 Kubernetes 的 架构 


Kubernetes 使 用 Etcd 作 为 存储 中 间 件 ，Etcd 是 一 个 高 可 用 的 键 值 存 
储 系统 ， 灵 感 来 目 于 ZooKeeper 和 Doozer， 通 过 Raft 一 致 性 算法 处 理 日 
志 复 制 以 保证 强 一 致 性 。Kubernetes 使 用 Etcd 作 为 系统 的 配置 存储 中 
>, Kubernetes 中 的 重要 数据 都 是 持久 化 在 Etcd 中 的 ， 这 使 得 
Kubermnetes 染 构 的 各 个 组 件 属于 无 状态 ， 可 以 更 简单 地 实施 分 布 式 集 
群 部 署 。 


Kubernetes Master 作 为 控制 节点 ， 调 度 管 理 整 个 系统 ， 包 含 以 下 
组 件 。 


e Kubernetes API Server: 作为 Kubernetes 系 统 的 入 口 ， 其 封装 了 核 
心 对 象 的 增删 改 查 操作 ， 以 REST API 接 口 方式 提供 给 外 部 客户 和 内 部 
组 件 调用 。 它 维护 的 REST 对 象 将 持久 化 到 Etcd 中 。 


e Kubernetes Scheduler: 负责 集群 的 资源 调度 ， 为 新 建 的 Pod 分 配 
FLES ° Dr LTE4 er DAR RIRA RT IRJ TE ERTR B. 
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表 2-1 所 示 。 


表 2-1 Kubernetes 控制 器 


控制 器 说 明 

Replication Controller 管理 维护 Replication Controller， 关 联 Replication Controller 和 Pod， 

保证 Replication Controller 定 义 的 副本 数量 与 实际 运行 Pod 的 数量 是 
- 致 的 

Node Controller 管理 维护 Node， 定 期 检查 Node 的 健康 状态 ， 标 识 出 失效 的 Node 

Namespace Controller 管理 维护 Namespace， 定 期 清理 无 效 的 Namespace， 包 括 Namespace 

下 的 API 对 象 ， 像 Pod、Service 和 Secret 等 

Service Controller 管理 维护 Service， 为 LoadBalancer 类 型 的 Service 创 建 管理 负载 均衡 

fit 

Endpoints Controller 管理 维护 Endpoints， 关 联 Service 和 Pod， 创 建 Endpoints 作 为 Service 

的 后 端 ， 当 Pod 发 生变 化 时 ， 实 时 刷新 Endpoints 

Service Account Controller 管理 维护 Service Account ， 为 每 个 Namespace 创 建 默认 Service 


Account， 同 时 为 Service Account 创 建 Service Account Secret 


Persistent Volume Controller 管理 维护 Persistent Volume fll Persistent Volume Claim， 为 新 的 
Persistent Volume Claim 分 配 Persistent Volume 进 行 绑 定 ， 为 释放 的 
Persistent Volume 执 行 清理 回收 

Daemon Set Controller 管理 维护 Daemon Set， 负 责 创 建 Daemon Pod， 保 证 指定 的 Node 上 


行 Daemon Pod 


Deployment Controller 管理 维护 Deployment， 关 联 Deployment 和 Replication Controller， 保 
证 运行 指定 数目 的 Pod。 当 Deployment 更 新 时 , 控制 实现 Replication 
Controller 和 Pod 的 更 新 

Job Controller 管理 维护 Job， 为 Job 创 建 一 次 性 任务 Pod， 保 证 完成 Job 指 定 完成 的 
任务 数目 

Pod Autoscaler Controller 实现 Pod 的 自动 伸缩 ， 定 时 获取 监控 数据 ， 进 行 策略 匹配 ， 当 满足 
条 件 时 执行 Pod 的 伸缩 动作 


Kubernetes Node 是 运行 节点 ， 用 于 运行 管理 业务 的 容器 ， 包 含 以 
下 组 件 。 


e Kubelet: 负责 管控 容器 ， Rab ae Ke me API Server 接 收 
Pod 的 创建 请 求 ， 局 动 和 停止 容 絮 ， 监 控 容 器 运行 状态 并 汇报 给 


Kubernetes API Server ° 


e Kubernetes Proxy: 负责 为 Pod 创 建 代理 服务 ，Kubernetes Proxy 
会 从 Kubernetes API Server 获 取 所 有 的 Service， 并 根据 Service 信 息 创 建 
代理 服务 ， 实 现 Service 到 Pod 的 请 求 路 由 和 转发 ， 从 而 实现 Kubernetes 
层级 的 虚拟 转发 网 络 。 


ini 


e Docker: Kubernetes Node 是 容器 运行 斑点 ， 需 要 运行 Docker 服 
务 ， 目 前 Kubernetes 也 文 持 Rocket， 这 是 一 款 CoreOS 开 发 的 类 Docker 
的 开源 容器 引擎， 本 书 只 说 明 Docker。 


22 ”部 署 Kubernetes 


Kubernetes 能 够 运行 在 各 个 平台 上 ， 包 括 物理 机 、 虚 拟 机 和 云 平 

o 在 部 署 方式 上 ，Kubernetes 可 以 在 生产 环境 中 大 规模 地 进行 分 布 
Aum. 也 可 以 简单 地 运行 在 单机 中 以 用 于 测试 开发 ， 我 们 可 以 根据 
不 同 的 需求 搭建 不 同 的 Kubernetes 运 行 环境 。 


Kubernetes 官 方 和 社区 针对 不 同系 统 和 平台 提供 了 目 动 化 部 署 脚 
本 ， 上 县 体 情况 如 表 2-2 所 示 。 


322-2 Kubernetes 部 署 支持 


接 下 来 我 们 将 详细 说 明 Kubernetes 的 部 署 步 
Kubernetes 的 一 些 概念 ， 可 以 进一步 帮助 
原理 。 


ERE BIG 
ag E | 一 本 一 


一 一 Azure CO C 
Docker Single Node Docker Single Node local 


Docker Multi Node Docker Multi Node 


Bare-metal Bare-metal Fedora 


Digital Ocean Digital Ocean Fedora "alic 
[ww o [EM — fm 


Mesos/Docker Mesos/Docker Ubuntu Docker 

ER E EE 
CoreOS flannel 

FEES REESE EE -EE 


| Vagrant Cd | Vagrant sd | Core0S — | 


Bare-metal Bare-metal CoreOS Calico 

CloudStack CloudStack 

VMware VMware Debian 

Bare-metal eo = 
| Ubuntu — —— | 


[aws | 
Joyent Joyent Ubuntu flannel 

AWS AWS Ubuntu 
Azure Azure Ubuntu OpenVPN 
Bare-metal Bare-metal Ubuntu 
Bare-metal Bare-metal Ubuntu flannel ^ | 
ws ua | | 
pw 0 [mm S 


2.2.1 ”环境 准备 


又 ， 同 时 也 会 涉及 
读者 理解 Kubernetes 的 架构 和 


Kubemetes 是 一 个 分 布 式 架构 ， 可 灵活 地 进行 安装 部 署 ， 可 以 部 
署 在 单机 ， 也 可 以 分 布 式 部 署 。 机 器 可 以 是 物理 机 ， 也 可 以 是 虚拟 
机 ， 但 是 需要 运行 Linux (x86 64) 操作 系统 ， 至 少 1 核 CPU 和 1GB 内 
TZ © 


本 书 准 备 了 4 台 虚 拟 机 (CentOS 7.0 系 统 ) 用 于 部 署 Kubernetes 运 
行 环境 ， 包 括 一 个 Etcd、 一 个 Kubernetes Master 和 三 个 Kubernetes 
Node， 如 表 2-3 所 示 。 


322-3 Kubernetes 运行 环境 


节点 主机 名 IP 
Etcd etcd 192.168.3.145 
Kubernetes Master kube-master 192.168.3.146 


Kubernetes Node 1 kube-node-1 192.168.3.147 
Kubernetes Node 2 kube-node-2 192.168.3.148 
Kubernetes Node 3 kube-node-3 192.168.3.149 


使 用 的 各 种 软件 版 本 信息 如 表 2-4 所 示 。 


表 2-4 软件 版 本 


软件 
Kubernetes 
Docker 
Etcd 


Flannel 


Open vSwitch 


提示 


本 书后 续 的 实践 操作 都 在 此 套 环 境 中 运行 


2.2.2 ”运行 Etcd 


Kubernetes 依 赖 于 Etcd， 需 要 先 部 署 Etcd， 可 以 从 Github 上 下 载 指 
定 版 本 的 Etcd 发 布 包 


$ wget 
https://github.com/coreos/etcd/releases/download/v2.2.0/etcd- 
v2.2.0-linux-amd64. tar.gz 

$ tar xzvf etcd-v2.2.0-linux-amd64. tar.gz 

$ cd etcd-v2.2.0-linux-amd64 

$ cp etcd /usr/bin/etcd 

$ cp etcdctl /usr/bin/etcdctl 


运行 Etcd: 


$ etcd -name etcd \ 

-data-dir /var/lib/etcd \ 

-listen-client-urls http://0.0.0.0:2379, http://0.0.0.0:4001 \ 
-advertise-client-urls http://0.0.0.0:2379, http://0.0.0.0:4001 
\ 

>> /var/log/etcd.log 2>&1 & 


Etcd 运 行 后 可 以 查询 其 健康 状态 : 


$ etcdctl -C http://etcd:4001 cluster-health 
member ce2a822cea30bfca is healthy: got healthy result from 
http://etcd: 4001 


cluster is healthy 


2.23 ”获取 Kubernetes 发 布 包 


Kubernetes 发 布 包 可 以 从 Github 上 下 载 ， 本 书 使 用 的 是 Kubernetes 
V1.1.1 版 本 : 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/vi1.1 
.1/kubernetes.tar.gz 


$tar zxvf kubernetes.tar.gz 
Kubermetes 发 布 包 中 包含 如 下 内 容 。 
e cluster: Kubernetes 目 动 化 部 署 脚本 。 
e contrib: Kubernetes 非 必需 程序 。 
* examples: Kubernetes 示 例 配置 文件 。 
。docs: Kubernetes 文 档 。 
* platforms: Kubernetes 的 命令 行 工 具 kubectl ° 
e server: Kubernetes 组 件 。 
* third. party: 第 三 方程 序 。 


Kubemetes 发 布 包 中 的 server/kubernetes-server-linux-amd64.tar.gz 包 


售 各 个 组 件 的 可 执行 程序 ， 将 这 些 可 执行 程序 复制 到 Linux 系 统 
孙 /use/bin/ 下 : 


$ cd kubernetes/server 
$ tar zxvf kubernetes-server -linux-amd64. tar.gz 
$ cd kubernetes/server/bin/ 


$ find ./ -perm 755 | xargs -i cp {} /usr/bin/ 


2.2.4 运行 Kubernetes MasterZH £F 


在 Kubernetes Master 上 需要 运行 以 下 组 件 : 
* Kubernetes API Server 

* Kubernetes Controller Manager 

* Kubernetes Scheduler 

e Kubernetes Proxy (可 选 ) 

Kubernetes API Server 


运行 Kubernetes API Server: 


$ kube-apiserver \ 

--logtostderr=true --v=0 ^ 
--etcd_servers=http://etcd:4001 \ 
--insecure-bind-address=0.0.0.0 --insecure-port=8080 \ 
--service-cluster-ip-range=10.254.0.0/16 \ 


>> /var/log/kube-apiserver.log 2>&1 & 


Kubernetes Controller Manager 


运行 Kubernetes Controller Manager: 


$ kube-controller-manager \ 
--logtostderr=true --v=0 \ 
--master=http://kube-master:8080 \ 


>> /var/log/kube-controller-manager.log 2>&1 & 


Kubernetes Scheduler 


运行 Kubernetes Scheduler: 


$ kube-scheduler \ 
--logtostderr=true --v=0 \ 
--master=http://kube-master:8080 \ 


>> /var/log/kube-scheduler.log 2>&1 & 


Kubernetes Proxy 


运行 Kubernetes Proxy: 


$ kube-proxy \ 
--logtostderr=true --v=0 ^ 
--api_servers=http://kube-master:8080 \ 


>> /var/log/kube-proxy.log 2>&1 & 


2.2.5 ”运行 Kubernetes Node 组 件 


Kubernetes Node 上 需要 运行 以 下 组 件 : 


* Docker 
* Kubelet 
* Kubernetes Proxy 


Docker 


Docker 官方 社区 提供 各 个 平台 的 安装 方法 (可 参考 
http://docs.docker.com/installation/) ， 很 多 Linux 发 行 版 都 陆续 对 Docker 
进行 了 文 持 ， 可 以 使 用 以 下 方式 快速 安装 Docker: 


$ curl -SSL https://get.docker.com/ | sh 


提示 


1. Docker 要 求 Linux 64 系 统 ， 并 且 内 核 至 少 3.10 版 本 以 上 。 


2. 不 同 的 Kubernetes 版 本 对 Docker 的 版 本 要 求 可 能 会 有 不 同 ， 
总 体 上 我 们 建议 使 用 最 新 稳定 的 Docker 版 本 ， 如 果 Kubelet 发 现 
Docker 版 本 过 低 ， 在 创建 Pod 的 时 候 会 失败 并 发 出 告警 日 志 。 


启动 Docker: 


$ docker -d \ 
-H unix:///var/run/docker.sock -H 0.0.0.0:2375 \ 
>> /var/log/docker.log 2>&1 & 


Kubelet 
运行 Kubelet: 


$ kubelet \ 

--logtostderr=true --v=0 \ 
--config=/etc/kubernetes/manifests \ 
--address=0.0.0.0 \ 
--api-servers=http://kube-master:8080 \ 
>> /var/log/kubelet.log 2>&1 & 


Kubernetes Proxy 
运行 Kubelet Proxy: 


$ kube-proxy \ 
--logtostderr=true --v=0 ^ 
--api servers-http://kube-master:8080 \ 


>> /var/log/kube-proxy.log 2>&1 & 


2.2.6 ”查询 Kubernetes 的 健康 状态 


在 部 署 运行 各 个 组 件 以 后 ， 可 以 通过 Kubernetes 命 令 行 kubect 查 询 
Kubernetes Master 各 组 件 的 健康 状态 : 


$ kubectl -s http://kube-master:8080 get componentstatus 
NAME STATUS MESSAGE ERROR 


controller-manager Healthy ok nil 


scheduler Healthy ok nil 
etcd-0 Healthy {"health": "true") nil 


以 及 Kubernetes Node 的 健康 状态 : 


$ kubectl -s http://kube-master:8080 get node 


NAME LABELS 
STATUS AGE 

kube-node-1 kubernetes.io/hostname-kube-node-1 Ready 
19m 

kube-node-2 kubernetes.io/hostname-kube-node-2 Ready 
18m 

kube-node-3 kubernetes.io/hostname-kube-node-3 Ready 
18m 


22.7 MÆKubernetes 28 


Kubemetes 的 网 络 模型 要 求 每 一 个 Pod 都 拥有 一 个 局 平 化 共享 网 络 
命名 空间 的 卫 ， 称 为 PodIP，Pod 能 够 直接 通过 PodIP 跨 网 络 与 其 他 物理 
机 和 了 Pod 进 行 通信 。 要 实现 Kubernetes 的 网 络 模型 ， 需 要 在 Kubernetes 
集群 中 创建 一 个 覆盖 网 络 (Overlay Network) ， 联 通 各 个 节点 ， 目 前 
可 以 通过 第 三 方 网 络 插件 来 创建 覆盖 网 络 ， 比 如 Flannel 和 Open 


vSwitch ° 


提示 


本 书 中 用 到 的 Kubernetes 运 境 主 要 是 使 用 Flannel 实 现 容器 
覆盖 网 络 的 。 


Flannel 


Flannel 是 CoreOS 团 队 设 计 开 发 的 一 个 履 蔓 网 络 工 具 ， 可 以 从 
Github 上 下 载 指定 版 本 的 Flannel 发 布 包 : 


$ wget 
https://github.com/coreos/flannel/releases/download/v0.5.4/flan 
nel-0.5.4-linux- 

amd64.tar.gz 

$ tar xzvf flannel-0.5.4-linux-amd64.tar.gz 

$ cd flannel-0.5.4 

$ cp flanneld /usr/bin 


Flannel f£ Fl Etcdi# £7 Fi , m 证 多 个 Flannel 实 例 之 间 的 配置 一 
致 性 ， 所 以 需要 首先 在 Etcd 上 进行 配置 ; 


$ etcdctl -C http://etcd:4001 \ 


set /coreos.com/network/config '{ "Network": "10.0.0.0/16" }' 


在 Kubernetes 的 所 有 节点 上 运行 Flannel: 


$ flanneld -etcd-endpoints=http://etcd:4001 \ 
>> /var/log/flanneld.log 2>&1 & 


Flannel & H ^f [E] Node B) Docker W) E Hc & ^^ [8] HJ IP Pd Ex LA PR uE 
Docker 容 属 的 卫 在 集群 内 唯一 ， 所 以 Flannel 会 重新 配置 Docker 网 桥 ， 
需要 先 删 除 原先 创建 的 Docker 网 桥 : 


$ iptables -t nat -F 
$ ifconfig dockerO down 


$ brctl delbr dockerO 


Flannel 运 行 后 会 生成 一 个 文件 subnet.env， 其 中 包含 规划 好 的 
Docker 网 桥 网 段 ， 根 据 其 中 的 属性 重新 启动 Docker: 


$ source /run/flannel/subnet.env 

$ docker -d \ 

-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 \ 
- -bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} \ 

>> /var/log/docker.log 2>&1 & 


Open vSwitch 


Open vSwitch 是 一 个 高 质量 的 、 多 层 虚 拟 交 换 机 ， 使 用 开源 
Apache 2.0 许 可 协议 ， 由 Nicira Networks 开 发 。 它 的 目的 是 让 大 规模 网 
络 目 动 化 可 以 通过 编程 扩展 ， 同 时 仍然 支持 标准 的 管理 接口 和 协议 。 
Open vSwitch 是 一 项 非常 重要 的 SDN 技 术 ， 可 以 实现 Kubernetes 中 的 改 
iti PAS o 


73 DR UE Docker Z 28 HY IPE SE E PATE — , f [B] Kubernetes Node 的 
Docker 网 桥 配置 成 不 同 的 IP 网 段 ， 需 要 进行 规划 ， 如 表 2-5 所 示 。 


322-5 Kubernetes Node 的 Docker 网 桥 规划 


节点 主机 名 IP Docker 网 桥 


Kubernetes 
Node 1 


kube-node-1 192.168.3.147 10.246.0.1/24 


Kubernetes 

kube-node-2 192.168.3.148 10.246.1.1/24 
Node 2 
Kubernetes 

kube-node-3 192.168.3.149 10.246.2.1/24 
Node 3 


安装 运行 Open vSwitch 服 务 以 后 ， 可 以 下 载 一 个 工具 来 协助 创建 
Open vSwitch 网 络 : 


$ wget https://raw.githubusercontent.com/wulonghui/docker-net- 
tools/master/k8s-ovs-ctl 
$ chmod 0750 k8s-ovs-ctl 


$ mv k8s-ovs-ctl /usr/bin/ 


TEKubernetes Node 上 配置 ~ /k8s-ovs.env: 


e Kubernetes Node 1 


DOCKER BRIDGE-dockerO 

CONTAINER ADDR-10.246.0.1 
CONTAINER NETMASK-255.255.255.0 
CONTAINER SUBNET-10.246.0.0/16 


OVS SWITCH-obrO 


TUNNEL_BASE=gre 
DOCKER OVS TUN-tunO 


LOCAL IP-192.168.3.147 
NODE IPS-(192.168.3.147 192.168.3.148 192.168.3.149) 
CONTAINER SUBNETS-(10.246.0.1/24 10.246.1.1/24 10.246.2.1/24) 


e Kubernetes Node 2 


DOCKER BRIDGE-dockerO 

CONTAINER ADDR-10.246.1.1 
CONTAINER NETMASK-255.255.255.0 
CONTAINER SUBNET-10.246.0.0/16 


OVS SWITCH-obrO 
TUNNEL BASE-gre 
DOCKER OVS TUN-tunO 


LOCAL IP-192.168.3.148 
NODE IPS-(192.168.3.147 192.168.3.148 192.168.3.149) 
CONTAINER SUBNETS-(10.246.0.1/24 10.246.1.1/24 10.246.2.1/24) 


e Kubernetes Node 3 


DOCKER BRIDGE-dockerO 

CONTAINER ADDR-10.246.2.1 
CONTAINER NETMASK-255.255.255.0 
CONTAINER SUBNET-10.246.0.0/16 


OVS SWITCH-obrO 
TUNNEL BASE-gre 


DOCKER OVS TUN-tunO 


LOCAL IP-192.168.3.149 
NODE IPS-(192.168.3.147 192.168.3.148 192.168.3.149) 
CONTAINER SUBNETS-(10.246.0.1/24 10.246.1.1/24 10.246.2.1/24) 


配置 完成 后 ， 先 删除 原先 创建 的 Docker 网 桥 : 


$ iptables -t nat -F 
$ ifconfig dockerO down 


$ brctl delbr dockerO 

然后 使 用 k8s-ovs-ctl 创 建 Open vSwitch 网 络 : 
$ k8s-ovs-ctl setup 

最 后 重新 运行 Docker: 


$ docker -d \ 

-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 \ 
--bridge=dockerO \ 

>> /var/log/docker.log 2>&1 & 


2.3 ”安装 Kubernetes 扩 展 插件 


Kubemetes 中 提供 了 许多 平台 扩展 插件 (Cluster Add-on) , 
在 Kubernetes 发 布 包 中 ， 可 以 在 Kubernetes 上 进行 安装 部 署 ， 目 前 包 人 台 
以 下 扩展 插件 : 


* Cluster DNS 
* Cluster Monitoring 
* Cluster Logging 


e Kube UI 


提示 


Kubernetes 平 台 扩 展 插件 并 不 是 必需 的 ， 初 次 部 署 可 以 跳 过 此 
章节 ， 待 后 续 阅 读 中 有 需要 再 进行 安装 。 


2.3.1 ”安装 Cluster DNS 

Cluster DNS 扩 展 插件 用 于 支持 Kubernetes 的 服务 发 现 机 市， 
Cluster DNS 主要 包含 如 下 几 项 。 

。SkyDNS: 提供 DNS 解析 服务 。 


。Etcd: 用 于 SkyDNS 的 存储 。 


* Kube2sky: 监听 Kubernetes， 当 有 新 的 Service 创 建 时 ， 生 成 相应 
记录 到 SkyDNS 。 


下 载 Kubernetes 发 布 包 ，Cluster DNS 扩展 插件 在 Kubernetes 发 布 包 
BJcluster/addons/dns H 5€ F : 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/dns 


通过 环境 变量 配置 参数 : 


$ export DNS_SERVER_IP="10.254.10.2" 
$ export DNS _DOMAIN="cluster.local" 


$ export DNS REPLICAS-1 


设置 Cluster DNS ServerHIP 7j10.254.10.2, Cluster DNS 的 本 地 域 
为 clusterlocal， 另 外 需要 配置 到 Kubelet 的 启动 参数 中 : 


--cluster-dns=10.254.10.2 


--cluster-domain=cluster.local 


Kubernetes AX fi &J cluster/addons/dns H ?& F 85 skydns-rc.yaml.in fll 
skydns-svc.yaml.in 是 两 个 模板 文件 ， 通 过 设置 的 环境 变量 修改 其 中 相 
应 的 属性 值 ， 生 成 Replication Controller 和 Service 的 定义 文件 : 


$ sed -e "s/(t pillar\['dns_replicas'\] 
}}/${DNS_REPLICAS}/g;s/{{ pillar\['dns_ 


domain'\]}}/${DNS_DOMAIN}/g;" \skydns-rc.yaml.in > skydns- 
rc.yaml 

$ sed -e "s/(( pillarN['dns server'N] }}/${DNS_SERVER_IP}/g" 
skydns-svc.yaml.in » 


skydns-svc.yaml 


Cluster DNS Replication Controller 的 定义 文件 skydns-rc.yaml 如 下 : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: kube-dns-v9 
namespace: kube-system 
labels: 
k8s-app: kube-dns 
version: v9 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: kube-dns 
version: v9 
template: 
metadata: 
labels: 
k8s-app: kube-dns 


version: v9 


kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: etcd 

image: gcr.io/google containers/etcd:2.0.9 
resources: 

limits: 

cpu: 100m 
memory: 50Mi 

command: 
- /usr/local/bin/etcd 
- -data-dir 
- /var/etcd/data 
- -listen-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -advertise-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -initial-cluster-token 
- skydns-etcd 
volumeMounts: 
- name: etcd-storage 

mountPath: /var/etcd/data 

- name: kube2sky 

image: gcr.io/google containers/kube2sky:1.11 
resources: 

limits: 


cpu: 100m 


memory: 50Mi 
args: 
# command = "/kube2sky" 
- -domain=cluster.local 
- -kube_master_url=http://kube-master : 8080 
- name: skydns 
image: gcr.io/google containers/skydns:2015-10-13- 
8c72f8c 
resources: 
limits: 
cpu: 100m 
memory: 50Mi 
args: 
# command = "/skydns" 
- -machines=http://127.0.0.1:4001 
- -addr=0.0.0.0:53 
- -ns-rotate=false 
- -domain=cluster.local. 
ports: 
- containerPort: 53 
name: dns 
protocol: UDP 
- containerPort: 53 
name: dns-tcp 
protocol: TCP 
livenessProbe: 


httpGet: 


path: /healthz 
port: 8080 
scheme: HTTP 
initialDelaySeconds: 30 
timeoutSeconds: 5 
readinessProbe: 
httpGet: 
path: /healthz 
port: 8080 
scheme: HTTP 
initialDelaySeconds: 1 
timeoutSeconds: 5 
- name: healthz 
image: gcr.io/google containers/exechealthz:1.0 
resources: 
limits: 
cpu: 10m 
memory: 20Mi 
args: 
- -cmd=nslookup kubernetes.default.svc.cluster.local 
localhost »/dev/null 
- -port-8080 
ports: 
- containerPort: 8080 
protocol: TCP 
volumes: 


- name: etcd-storage 


emptyDir: {} 


dnsPolicy: Default # Don't use cluster DNS. 


kube2sky 需要 Service Account 2E 75] Hj Kubernetes API, 4) R 
Kubernetes 没 有 开启 Service Account， 可 以 显 式 指定 Kubernetes API 
的 URL， 在 skydns-rc.yaml 中 设置 Kube2sky 的 启动 参数 如 下 所 示 。 


args: 
# command = "/kube2sky" 


- -domain=cluster.local 


通过 定义 文件 创建 Cluster DNS Replication Controller: 


$ kubectl create -f skydns-rc.yaml 


replicationcontroller "kube-dns-v9" created 


Cluster DNS Replication Controller?!) 3447 Cluster DNS Pod: 


$ kubectl get pod --selector k8s-app-kube-dns --namespace-kube- 


system 
NAME READY STATUS RESTARTS AGE 
kube-dns-v9-qdck6 4/4 Running 0 2m 


Cluster DNS Service 的 定义 文件 skydns-svc.yaml: 


apiVersion: v1 

kind: Service 

metadata: 
name: kube-dns 
namespace: kube-system 
labels: 


k8s-app: kube-dns 


kubernetes.io/cluster-service: 


kubernetes.io/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 


clusterIP: 10.254.10.2 


ports: 
- name: dns 
port: 53 


protocol: UDP 
- name: dns-tcp 
port: 53 


protocol: TCP 


"true" 


通过 定义 文件 创建 Cluster DNS Service: 


$ kubectl create -f skydns-svc.yaml 


service "kube-dns" created 


然后 可 以 查询 Cluster DNS Service: 


$ kubectl get service -1 k8s-app-kube-dns --namespace=kube- 


system 

NAME CLUSTER IP EXTERNAL IP PORT(S) 
SELECTOR AGE 

kube-dns 10.254.10.2 «none» 53/UDP, 53/TCP k8s- 


app=kube-dns 47S 


Cluster DNS 部 署 完成 后 ， 可 以 创建 Pod 进 行 验 证 : 


$ kubect1 exec my - pod -- nslookup 
kubernetes.default.cluster.local 
Server: 10.254.10.2 


Address 1: 10.254.10.2 


Name : kubernetes.default.cluster.local 


Address 1: 10.254.0.1 


2.3.2 "Cluster Monitoring 


Kubernetes f [I f Cluster Monitoring E 7j F & Ui fa 3 $$, Cluster 
Monitoring 的 主体 是 Heapster， 一 个 容器 集群 的 监控 收集 工具 ， 将 收集 
Kubernetes 运 行 平 台 的 监控 数据 ， 文 持 导 入 到 其 他 第 三 方 系统 ， 比 如 
InfluxDB 和 GCE。 


下 载 Kubernetes 发 布 包 ，Cluster Monitoring 扩 展 插件 在 Kubernetes 
发 布 包 的 cluster addons/cluster-monitoring H 5 F : 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1i.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/cluster-monitoring 


T£ Kubernetes % ^fi &J HJ cluster/addons/cluster-monitoring H 3x FF E 
以 下 子 目 录 ， 每 个 子 目录 中 存放 着 不 同 的 定义 文件 。 


e standalone: 部 署 独立 运行 的 Heapster 。 

。influxdb: 部 署 Heapster 对 接 InfluxDB。 

* google: 部 署 Heapster 对 接 GCE ° 

。googleinfluxdb: 部 署 Heapster 对 接 GCE 和 InfluxDB ° 


我 们 将 部 署 Heapster 对 接 InfluxDB，InfluxDB 是 一 个 开源 分 布 式 时 
序 、 事 件 和 指标 数据 库 ， 同 时 ，InfluxDB 集 成 Grafana 提 供 图 表 展 示 功 


能 。 
部 署 InfluxDB 和 Grafana 


Influxdb&Grafana Replication Controller 的 Æ X 文件 


influxdb/influxdb-grafana-controller. yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 


name: monitoring-influxdb-grafana-v2 


namespace: kube-system 
labels: 
k8s-app: influxGrafana 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: influxGrafana 
version: v2 
template: 
metadata: 
labels: 
k8s-app: influxGrafana 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: 
gcr.io/google containers/heapster influxdb:v0.4 
name: influxdb 
resources: 
limits: 
cpu: 100m 
memory: 200Mi 
ports: 


- containerPort: 8083 


hostPort: 8083 
- containerPort: 8086 
hostPort: 8086 
volumeMounts: 
- name: influxdb-persistent-storage 
mountPath: /data 
- image: 
beta.gcr.io/google_containers/heapster_grafana:v2.1.1 
name: grafana 
env: 
resources: 
limits: 
cpu: 100m 
memory: 100Mi 
env: 
# This variable is required to setup templates in 
Grafana. 
- name: INFLUXDB SERVICE URL 
value: http://monitoring-influxdb:8086 
# The following env variables are required to 
make Grafana accessible via 
# the kubernetes api-server proxy. On production 
clusters, we recommend 
# removing these env variables,setup auth for 
grafana,and expose the grafana 
# service using a LoadBalancer or a public IP. 


#- name: GF AUTH BASIC ENABLED 


# value: "false" 
#- name: GF_AUTH_ANONYMOUS_ENABLED 
# value: "true" 
#- name: GF_AUTH_ANONYMOUS_ORG_ROLE 
# value: Admin 
#- name: GF_SERVER_ROOT_URL 
# alue: /api/vi/proxy/namespaces/kube- 
system/services/monitoring-grafana/ 
volumeMounts: 
- name: grafana-persistent-storage 
mountPath: /var 
volumes: 
- name: influxdb-persistent-storage 
emptyDir: {} 
- name: grafana-persistent-storage 


emptyDir: {} 


influxdb/influxdb-grafana-controller.yaml F 33: #4 Grafana € $i B] 
环境 变量 : 


# The following env variables are required to make Grafana 
accessible via 
# the kubernetes api-server proxy. On production clusters, we 


recommend 


# removing these env variables,setup auth for grafana,and 
expose the grafana 
# service using a LoadBalancer or a public IP. 
#- name: GF_AUTH_BASIC_ENABLED 
# value: "false" 
name: GF_AUTH_ANONYMOUS_ENABLED 
value: "true" 
name: GF_AUTH_ANONYMOUS_ORG_ROLE 
value: Admin 
name: GF_SERVER_ROOT_URL 


alue: /api/v1/proxy/namespaces/kube- 


system/services/monitoring-grafana/ 


通过 定义 文件 创建 Influxdb&Grafana Replication Controller: 


$ kubectl create -f influxdb/influxdb-grafana-controller.yaml 


replicationcontroller "monitoring-influxdb-grafana-v2" created 


Influxdb&Grafana Replication Controller 创 建 运行 Influxdb&Grafana 
Pod: 


$ kubectl get pod  --selector  k8s-app-influxGrafana  -- 


namespace-kube-system --output wide 


NAME READY STATUS 
RESTARTS AGE NODE 
monitoring-influxdb-grafana-v2-v5e4y 2/2 Running 0 


10m kube -node -2 


在 Pod 的 查询 信息 中 ， 属 性 NODE 显 示 Pod 运 行 在 Node kube-node-2 
上 ， 因 为 Pod 中 为 mnfluxdb 容 器 设置 了 端口 映射 规则 (8083:8083) ， 于 
是 便 可 以 通过 Node kube-node-2 访 问 到 Influxdb 的 Web 界 面 ， 访 问 地 址 
是 http://kube-node-2:8083， 如 图 2-2 所 示 。 


kube-node-2 = 


Create a Database 


Retention Duration RegEx 


图 2-2 访问 Influxdb web 界面 


Influxdb Service 的 定义 文件 influxdb/influxdb-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: monitoring-influxdb 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "InfluxDB" 
spec: 
ports: 


- name: http 


port: 8083 
targetPort: 8083 
- name: api 
port: 8086 
targetPort: 8086 
selector: 


k8s-app: influxGrafana 


通过 定义 文件 创建 Influxdb Service: 


$ kubectl create -f influxdb/influxdb-service.yaml 


service "monitoring-influxdb" created 


Grafana Servicel 4E X. X  f'Finfluxdb/grafana-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: monitoring-grafana 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Grafana" 
spec: 
type: NodePort 
ports: 
- port: 80 


targetPort: 3000 


selector: 


k8s-app: influxGrafana 


其 中 设置 Grafana Service HJ X Æ 73 NodePort , ix FR — 3K , 
Kubernetes & 7j Service fi) f& — 4 9m O NodePort, ， 通 过 [Kubernetes Node 
IP]:[NodePort] 束 可 以 访问 到 Service ° 


通过 定义 文件 创建 Grafana Service: 


$ kubectl create -f influxdb/grafana-service.yaml 

You have exposed your service on an external port on all nodes 
in your 

cluster. If you want to expose this service to the external 
internet, you may 

need to set up firewall rules for the service port(s) 


(tcp:32075) to serve traffic. 


See http://releases.k8s.io/release-1.1/docs/user - 
guide/services-firewalls.md for more details. 


service "monitoring-grafana" created 


从 Grafana Service 创 建成 功 的 提示 中 可 以 知道 Kubernetes 分 配 的 
NodePort 是 tcp:32075 ， 那 么 通过 http:/kube-node-2:32075 可 以 访问 
Grafana， 如 图 2-3 所 示 。 


(Gicelielate) 


图 2-3 访问 Grafana 


部 署 Heapster 


Heapster Replication Controller 的 定义 X. ft influxdb/heapster- 


controller.yaml: 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: heapster-v10 
namespace: kube-system 
labels: 
k8s-app: heapster 
version: v10 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 


k8s-app: heapster 


version: v10 
template: 
metadata: 
labels: 
k8s-app: heapster 
version: v10 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: gcr.io/google containers/heapster:v0.18.2 
name: heapster 
resources: 
limits: 
cpu: 100m 
memory: 300Mi 
command: 
- /heapster 
- --source=kubernetes:http://kube-master : 8080? 
inClusterConfig- 
false&useServiceAccount-false 
- --sink-influxdb:http://monitoring-influxdb:8086 
- --stats resolution-30s 


- --Sink_frequency=im 


Heapster 需 要 Service Account ¥ Jal FJ Kubernetes API, W R 
Kubernetes 没 有 开局 Service Account, FJ DA i x RAE Kubernetes API 
的 URL， 可 在 skydns-rc.yaml 中 设置 Heapster 的 启动 参数 。 


command: 
- /heapster 
- --source=kubernetes:http://kube-master : 8080? 
inClusterConfig=false&useServiceAccount= 
false 
- --Sink=influxdb:http://monitoring-influxdb: 8086 
- --stats_resolution=30s 


- --Sink_frequency=1m 


通过 定义 文件 创建 Heapster Replication Controller: 


$ kubectl create -f influxdb/heapster-controller.yaml 


replicationcontroller "heapster-v10" created 


Heapster Replication Controller 创 建 运行 Heapster Pod: 


$ kubectl get pod --selector k8s-app-heapster --namespace-kube- 


system 
NAME READY STATUS RESTARTS AGE 
heapster-v10-s8jc1 1/1 Running 0 44s 


Heapsteri& S17 了 后 会 收集 Kubernetes 的 监控 数据 ， 导 入 到 InfluxDB， 
然后 束 可 以 通过 Grafana 但 看 数据 图 表 展 示 ， 如 图 2-4 所 示 。 


图 2-4 Grafanaf&znKubernetes i 


Heapster Service 的 定义 文件 influxdb/heapster-service.yaml: 


kind: Service 
apiVersion: vi 
metadata: 
name: heapster 
namespace: kube-system 
labels: 
kubernetes.io/cluster-service: "true" 


kubernetes.io/name: "Heapster" 


spec: 
ports: 
- port: 80 
targetPort: 8082 
selector: 


k8s-app: heapster 


通过 定义 文件 创建 Heapster Service: 


$ kubectl create -f influxdb/heapster-service.yaml 


service "heapster" created 


Heapster Service 创 建成 功 后 就 可 以 通过 Kubernetes API Server 提 供 
的 Proxy 接 口 调用 Heapster 的 Rest API: 


$ curl http://kube-master :8080/api/v1/proxy/namespaces/kube- 


system/services/heapster/api/v1/... 


2.3.3 ”安装 Cluster Logging 


Kubermetes#e ff T Cluster Logging FKE à H x, Cluster Logging 
fsi FA Fluentd+Elasticsearcht+ Kibana 来 收集 、 汇 总 和 展示 Kubernetes 运 行 
平台 的 日 志 。 


下 载 Kubernetes 发 布 包 ，Cluster Logging 扩 展 插件 在 发 布 包 的 


Kubernetes/cluster/addons/ fluentd-elasticsearch H 3€ F: 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1i.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/fluentd-elasticsearch 


288 lasticsearch 


Elasticsearch Replication Controller 的 定义 文件 es-controller.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: elasticsearch-logging-v1 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 2 
selector: 
k8s-app: elasticsearch-logging 
version: vi 
template: 
metadata: 
labels: 
k8s-app: elasticsearch-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 

containers: 

- image: gcr.io/google containers/elasticsearch:1.7 
name: elasticsearch-logging 
resources: 

limits: 


cpu: 100m 


ports: 
- containerPort: 9200 
name: db 
protocol: TCP 
- containerPort: 9300 
name: transport 
protocol: TCP 
volumeMounts: 
- name: es-persistent-storage 
mountPath: /data 
volumes: 
- name: es-persistent-storage 


emptyDir: {} 


通过 定义 文件 创建 Elasticsearch Replication Controller: 


$ kubectl create -f es-controller.yaml 


replicationcontroller "elasticsearch-logging-vi" created 


Elasticsearch Replication Controller ®!) 3447 Elasticsearch Pod: 


$ kubectl get pod --selector k8s-app=elasticsearch-logging -- 
namespace=kube-system 

NAME READY STATUS 
RESTARTS AGE 

elasticsearch-logging-vi-joxgq 1/1 Running 0 
48s 


elasticsearch-logging-v1-ofmn2 1/1 Running 


48S 


Elasticsearch Service 的 定义 文件 es-service.yaml: 


apiVersion: vi 
kind: Service 
metadata: 
name: elasticsearch-logging 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Elasticsearch" 
spec: 
ports: 
- port: 9200 
protocol: TCP 
targetPort: db 
selector: 


k8s-app: elasticsearch-logging 


通过 定义 文件 创建 Elasticsearch Service: 


$ kubectl create -f es-service.yaml 


service "elasticsearch-logging" created 


Elasticsearch Service 创 建成 功 后 ， 可 以 通过 Kubernetes API Server 
提供 的 Proxy 接 口 访问 Elasticsearch， 如 图 2-5 所 示 。 


图 2-5 访问 Elasticsearch API 


部 署 Kibana 


Kibana Replication Controller 的 定义 文件 kibana-controlleryaml: 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: kibana-logging-vi 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 


replicas: 1 


selector: 
k8s-app: kibana-logging 
version: vi 
template: 
metadata: 
labels: 
k8s-app: kibana-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kibana-logging 
image: gcr.io/google containers/kibana:1.3 
resources: 
limits: 
cpu: 100m 
env: 
- name: "ELASTICSEARCH URL" 
value: "http://elasticsearch-logging:9200" 
ports: 
- containerPort: 5601 
name: ui 


protocol: TCP 


通过 定义 文件 创建 Kibana Replication Controller: 


$ kubectl create -f kibana-controller.yaml 


replicationcontroller "kibana-logging-vi" created 


Kibana Replication Controller 创 建 运行 Kibana Pod: 


$ kubectl get pod --selector k8s-app=kibana-logging -- 


namespace=kube-system 


NAME READY STATUS 
AGE 
kibana-logging-vi-xqjhz 1/1 Running 1 


Kibana Service 的 定义 文件 kibana-service.yaml: 


apiVersion: vi 
kind: Service 
metadata: 
name: kibana-logging 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Kibana" 
spec: 
ports: 
- port: 5601 
protocol: TCP 


targetPort: ui 


RESTARTS 


2m 


selector: 


k8s-app: kibana-logging 


通过 定义 文件 创建 Kibana Service: 


$ kubectl create -f kibana-service.yaml 


service "kibana-logging" created 


Kibana Service 创 建成 功 后 ， 就 可 以 通过 Kubernetes API Server? tt 
的 Proxy 接 口 访 问 Kibana， 如 图 2-6 所 示 。 


kube-master = 


图 2-6 访问 Kibana 


部 署 Fluentd 


Fuente E Logging Agent 需 要 运行 在 所 有 Kubernetes 节 点 上 ， 我 
们 通过 Kubelet 将 其 作为 Static Pod (参考 12.1.1 节 ) 运行 。 


在 所 有 Kubernetes Node 上 , 在 Kubelet Bj EB 
录 /etc/kubernetes/manifests F 放 入 Fluentd Pod 的 定义 文件 fluentd- 


es.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 

name: fluentd-elasticsearch 

namespace: kube-system 

spec: 

containers: 

- name: fluentd-elasticsearch 
image: gcr.io/google containers/fluentd-elasticsearch:1.11 
resources: 

limits: 
cpu: 100m 
args: 
- -q 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
- name: varlibdockercontainers 
mountPath: /var/lib/docker/containers 
readOnly: true 

terminationGracePeriodSeconds: 30 

volumes: 

- name: varlog 
hostPath: 

path: /var/log 


- name: varlibdockercontainers 


hostPath: 


path: /var/lib/docker/containers 


— 


然后 Kubelet 就 会 在 所 有 Kubernetes Node 上 运行 Fluentd Pod: 


$ kubectl get pod --selector  k8s-app-fluentd-logging -- 


namespace=kube-system --output wide 
NAME 

RESTARTS AGE NODE 
fluentd-elasticsearch-kube-node-1 1/1 
1m kube-node-1 
fluentd-elasticsearch-kube-node-2 1/1 
1m kube-node-2 
fluentd-elasticsearch-kube-node-3 1/1 
1m kube-node-3 


READY STATUS 
Running 9 
Running 9 
Running 9 


Fluentd 运 行 后 ， 将 会 收集 日 志 并 导入 到 Elasticsearch， 从 而 可 以 通 


过 Kibana 查 询 到 日 志 ， 如 图 2-7 所 示 。 


i CHNSIRI T N 


图 2-7 Kibana 查 询 日 志 


2.3.4 ”安装 Kube UI 


Kube UI 是 Kubernetes 提 供 的 Web 管 理 界面 ， 下 载 Kubernetes Z ffi 
包 ，Kube UI 扩 展 搬 件 在 Kubernetes 发 布 包 的 clusteraddons/kube-ui 目 孙 
F: 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/cluster/addons/kube-ui 


Kube UI Replication Controller 的 定义 文件 kube-ui-rc.yaml: 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: kube-ui-v2 
namespace: kube-system 
labels: 
k8s-app: kube-ui 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 


k8s-app: kube-ui 


version: v2 
template: 
metadata: 
labels: 
k8s-app: kube-ui 
version: v2 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kube-ui 
image: gcr.io/google containers/kube-ui:v2 
resources: 
limits: 
cpu: 100m 
memory: 50Mi 
ports: 
- containerPort: 8080 
livenessProbe: 
httpGet: 
path: / 
port: 8080 
initialDelaySeconds: 30 


timeoutSeconds: 5 


通过 定义 文件 创建 Kube UI Replication Controller: 


$ kubectl create -f kube-ui-rc.yaml 


replicationcontroller "kube-ui-v2" created 


Kube UI Replication Controller 创 建 运行 Kube UI Pod: 


$ kubectl get pods -1 k8s-app=kube-ui --namespace-kube-system 


NAME READY STATUS RESTARTS AGE 


kube-ui-v2-69g00g 1/1 Running 0 


Kube UI Service 的 定义 文件 kube-ui-svc.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: kube-ui 
namespace: kube-system 
labels: 
k8s-app: kube-ui 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "KubeUI" 
spec: 
selector: 
k8s-app: kube-ui 
ports: 
- port: 80 


targetPort: 8080 


通过 定义 文件 创建 Kube UI Service: 


28S 


$ kubectl create -f kube-ui-rc.yaml 


replicationcontroller "kube-ui-v2" created 


Kube UI Service 创 建成 功 后 就 可 以 通过 Kubernetes API Server] £z 
口 访问 到 Kube UI， 如 图 2-8 所 示 。 
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图 2-8 ”访问 Kube UI 


第 3 章 
Kubernetes 快 速 入 门 


Kubemetes 是 容器 集群 管理 系统 ， 为 容器 化 的 应 用 提供 资源 调 
度 、 部 署 运行 、 容 灾 容 错 和 服务 发 现 等 功能 。 本 章 通过 一 个 完整 示例 
演示 Kubernetes 的 基本 功能 ， 其 中 涉及 Pod、Replication Controller Fil 
Service 这 三 个 Kubernetes 基 本 要 素 的 功能 展示 ， 从 而 帮助 读者 快速 理 
解 Kubernetes。 


3.1 示例 应 用 Guestbook 


本 章 要 演示 的 示例 应 用 是 一 个 名 叫 Guestbook 的 应 用 ，Guestbook 
是 一 个 典型 的 Web 应 用 。Guestbook 的 部 署 运 行 结 构 如 图 3-1 所 示 。 


Redis Slave Redis Slave : 


Replicate 


Guestbook & Wi 354) ° 


图 3-1Guestbook 结 构 


* Frontend 


Guestbook 的 Web 前 端 部 分 ， 无 状态 节点 ， 可 以 方便 伸缩 ， 本 例 中 
将 运行 3 个 实例 。 
* Redis 


Guestbook 的 存储 部 分 ，Redis 采 用 主 备 模式 ， 即 运行 1 个 Redis 
Master 和 2 个 Redis Slave, Redis Slave 会 从 Redis Master 同 步 数 据 。 


Guestbook 提 供 一 个 非 党 简单 的 功能 : TEFrontend H Al fe 22 BE , 
Frontend 则 将 数据 保存 到 Redis Master, IJa M Redis Slave 读 取 数 据 显 
示 到 页 面 上 。 


Guestbook5E X. XAF Kubernetes Z 78 ‘J examples/guestbook H 3x 
下 : 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1i.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/examples/guestbook 


32 ”准备 工作 


需要 准备 一 套 Kubemetes 运 行 环境 ， 可 参考 2.2 节 的 介绍 。 男 外 ， 
Kubernetes 需 要 安装 Cluster DNS， 可 参考 2.3.1 节 的 介绍 。 


本 文 使 用 的 Kubernetes 环 境 信 息 如 下 所 示 。 


$ kubectl cluster-info 

Kubernetes master is running at http://k8s-master : 8080 

KubeDNS is running at http://k8s- 
master :8080/api/v1/proxy/namespaces/kube-system/ 


services/kube-dns 


$ kubectl -s http://kube-master:8080 get componentstatuses 
NAME STATUS MESSAGE ERROR 
controller-manager Healthy ok nil 


scheduler Healthy ok nil 


etcd-0 Healthy ("health": "true") nil 


$ kubectl -s http://kube-master:8080 get nodes 


NAME LABELS 
STATUS AGE 

kube-node-1 kubernetes.io/hostname-kube-node-1 Ready 
19m 

kube-node-2 kubernetes.io/hostname-kube-node-2 Ready 
18m 

kube-node-3 kubernetes.io/hostname-kube-node-3 Ready 
18m 


3.3 jB47Redis 


首先 在 Kubernetes 上 部 署 运 行 Redis， 包 括 Redis Master Fi Redis 


Slave ° 


3.3.1 创建 Redis Master Pod 


Pod 是 Kubernetes 的 基本 处 理 单 元 ，Pod 包 含 一 个 或 者 多 个 相关 的 
容器 ， 应 用 将 以 Pod 的 形式 运行 在 Kubernetes 中 (本 质 上 是 运行 容 
fat) 。 而 Replication Controller 能 够 控制 Pod 按 照 指定 副本 数目 持续 运 
4T 
可 


， 一 般 情况 下 是 通过 Replication Controller 来 创建 Pod， 来 保证 Pod 的 


Redis Master Replication Controller 的 定义 文件 redis-master- 


controller.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 
spec: 
containers: 
- name: master 
image: redis 
ports: 


- containerPort: 6379 


在 Kubernetes 中 ， 主 要 通过 文件 来 定义 API 对 象 ， 定 义 文件 形式 更 
加 清晰 ， 也 方便 保存 和 修改 ， 定 义 文件 格 式 支 持 JSON 和 YAML， 本 书 
主要 使 用 YAML 格式。 


定义 文件 中 首先 声明 了 API 对 象 的 基本 属性 : API 版 本 
(.apiVersion) 、API 对 象 类 型 (kind) 和 元 数据 (metadata) ， 定 义 
文件 redis-master-controlleryaml 中 定义 了 V1 版 本 下 一 个 名 称 为 redis- 
master 的 Replication Controller ° Yh 4c Y Replication Controller 的 规 
格 (spec) ， 其 中 设置 了 Pod 的 副本 数 (.spec.replicas) 和 Pod 模 板 
(.spec.template) 。Pod 模 板 中 说 明了 Pod 包 含 一 个 容器 ， 该 容器 使 用 
镜像 redis， 即 运行 Redis Master， 该 Replication Controller 将 关联 1 个 这 
KH Pod, ft Replication Controller 和 Pod 的 关联 是 通过 Label 来 实现 
(.spec.selector 和 .spec.template.metadata.labels) 的 。 


通过 定义 文件 创建 Redis Master Replication Controller: 


$ kubectl create -f redis-master-controller.yaml 


replicationcontroller "redis-master" created 


创建 成 功 后 ， 可 查询 Redis Master Replication Controller: 


$ kubectl get replicationcontroller redis-master 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 

redis-master master redis name=redis-master 1 


15s 


Redis Master Replication Controller 将 会 创建 1 个 Redis Master Pod, 
创建 出 来 的 Pod 就 会 带 上 Label name-redis-master: 


$ kubectl get pod --selector name=redis-master 
NAME READY STATUS RESTARTS AGE 


redis-master-vdkfp 1/1 Running 0 31S 


Replication Controller 在 创建 出 Pod 以 后 ， 将 会 保证 Pod 按 照 指定 副 
本 数目 持续 运行 ， 而 通过 Replication Controller 也 可 以 对 Pod 进 行 一 系列 
操作 ， 包 括 滚动 升级 和 弹性 伸缩 等 。 


3.3.2 ”创建 Redis Master Service 


Kubernetes Pode 22 (LH), PERI <4 52 $l Replication Controller# 
TIERE, MS Pod ESS (LAYIN RE, PodHYIPth 28 (LHY ° SEL 
了 一 个 问题 : 在 Kubernetes 集 群 中 ，Pod 之 间 如 何 互 相 发 现 并 访问 呢 ? 
比如 我 们 已 经 运行 了 Redis Master Pod， 那 么 Redis Slave Pod 如 何 获取 
Redis Master Pod 的 访问 地 址 呢 ? 为 此 Kubernetes 提 供 了 Service 来 实现 
服务 发 现 。 


Kubernetes 中 Service 是 真实 应 用 的 抽象 ， 将 用 来 代理 Pod， 对 外 提 
供 固 定 IP 作 为 访问 入 口 ， 这 样 通 过 访问 Service 便 能 访问 到 相应 的 Pod， 
而 对 访问 者 来 说 只 需 知 道 Service 的 访问 地 址 ， 而 不 需要 感知 Pod 的 变 
化 。 


上 一 步 中 已 经 运行 起 Redis Master Pod， 现 在 创建 Redis Master 
Service 来 代理 Redis Master Pod, Redis Master Service 的 定义 文件 redis- 


master-service.yaml: 


apiVersion: vi 
kind: Service 
metadata: 

name: redis-master 


labels: 


name: redis-master 
spec: 
ports: 
# the port that this service should serve on 
- port: 6379 
targetPort: 6379 
selector: 


name: redis-master 


Service 是 通过 Label 来 关联 Pod 的 ， 在 Service 的 定义 中 ， 设 
置 .spec.selector 为 name= redis-master， 将 关联 上 Redis Master Pod 。 


通过 定义 文件 创建 Redis Master Service: 


$ kubectl create -f redis-master-service.yaml 


service "redis-master" created 


创建 成 功 后 查看 Redis Master Service: 


$ kubectl get service redis-master 


NAME CLUSTER_IP EXTERNAL_IP PORT(S) 
SELECTOR AGE 
redis-master 100.254.233.212 <none> 6379/TCP 


name=redis-master 13s 


Redis Master Service 的 查询 信息 中 显示 属性 CLUSTER_IP 为 
10.254.233.212 ， 属 性 PORT(S) 为 6379/TCP ， 其 中 10.254.233.212 是 
Kubernetes 分 配给 Redis Master Service 的 虚拟 IP，6379/TCP 则 是 Service 
会 转发 的 端口 (通过 Service 定 义 文件 中 的 .spec.ports[0].port 指 定 ) ， 


Kubernetes 会 将 所 有 访问 10.254.233.212:6379 的 TCP 请 求 转发 到 Redis 
Master Pod 中 ， 目 标 端口 是 6379/TCP (通过 Service 定 义 文件 中 的 
spec.ports[0].targetPort 指 定 ) ° 


为 创建 了 Redis Master Service 来 代理 Redis Master Pod, ft DA 
Redis Slave Pod 通 过 Redis Master Service 的 虚拟 IP 10.254.233.212 就 可 以 
访问 到 Redis Master Pod， 但 是 如 采 只 是 硬 配置 Service 的 虚拟 卫 到 Redis 
Slave Pod 中 ， 这 样 还 不 是 真正 的 服务 发 现 ，Kubernetes 提 供 了 两 种 发 
现 Service 的 方法 。 


“ 环境 变量 


当 Pod 运 行 的 时候 ，Kubernetes 会 将 之 前 存在 的 Service 的 信息 通过 
环境 变量 写 到 Pod 中 ， 以 Redis Master Service 为 例 ， 它 的 信息 会 被 写 到 
Pod: 


REDIS MASTER SERVICE HOST-10.254.233.212 
REDIS MASTER PORT 6379 TCP PROTO-tcp 


REDIS MASTER SERVICE PORT-6379 
REDIS MASTER PORT-tcp://10.254.233.212:6379 
REDIS MASTER PORT 6379 TCP-tcp://10.254.233.212:6379 


REDIS MASTER PORT 6379 TCP PORT-6379 


REDIS MASTER PORT 6379 TCP ADDR-10.254.233.212 


这 种 方法 要 求 Pod 必 须 在 Service 之 后 局 动 ， 之 前 局 动 的 Pod 没 有 这 
些 环境 变量 。 采 用 DNS 方式 就 没有 这 个 限制 。 


«DNS 


当 有 新 的 Service 创 建 时 ， 就 会 目 动 生 成 一 条 DNS 记录 ， 以 Redis 
Master Service 为 例 ， 有 一 条 DNS 记录 : 


redis-master => 10.254.233.212 


使 用 这 种 方法 ，Kubernetes 需 要 安装 Cluster DNS, FJ B24 2.3.17) 
的 介绍 。 


3.3.3 ”创建 Redis Slave Pod 


iH wf Replication Controller 可 创建 Redis Slave Pod， 将 创建 两 个 
Redis Slave Pod ° Redis Slave Replication Controller #9 E Y. X. ff redis- 


slave-controller.yaml: 


kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 


template: 


metadata: 
labels: 
name: redis-slave 
spec: 
containers: 
- name: worker 
image: gcr.io/google_samples/gb-redisslave:v1 
env: 
- name: GET_HOSTS_FROM 
value: dns 
# If your cluster config does not include a dns 
service, then to 
# instead access an environment variable to find the 
master 
# service's host, comment out the 'value: dns' line 
above, and 
# uncomment the line below. 
# value: env 
ports: 


- containerPort: 6379 


Redis Slave Replication Controller 定 义 中 设置 Pod 副 本 数 为 2， 而 
Pod PX Dx PHAR —hA at, A as 18 A Bi gcrio/google samples/gb- 
redisslave:v1， 该 镜像 实际 上 是 基于 镜像 redis 重 写 了 启动 脚本 ， 将 作为 
Redis Master 的 备 节 点 局 动 ， 启 动 脚 本 如 下 : 


if [[ ${GET_HOSTS_FROM:-dns} == "env" ]]; then 
redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 6379 
else 
redis-server --slaveof redis-master 6379 


fi 


其 中 通过 环境 变量 GET_HOSTS_FROM 来 控制 使 用 环境 变量 或 者 
DNS 方式 来 发 现 Redis Master Server ° 


提示 


镜像 gcrio/google_samples/gb-redisslave:v1 的 Dockerfile 人 参考 : 


https://github.com/kubernetes/kubernetes/tree/vi.1.1/examples 


/guestbook/redis-slave 


通过 定义 文件 创建 Redis Slave Replication Controller: 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontroller "redis-slave" created 


创建 成 功 后 ， 查 询 Redis Slave Replication Controller: 


$ kubectl get replicationcontroller redis-slave 
CONTROLLER CONTAINER(S) IMAGE(S) 
SELECTOR REPLICAS AGE 


redis-slave worker gcr.io/google samples/gb- 


redisslave:v1i name-redis-slave 2 As 


Redis Slave Replication Controller 创 建 运 行 两 个 Redis Slave Pod: 


$ kubectl get pod --selector name=redis-slave 


NAME READY STATUS RESTARTS 
redis-slave-79617 1/1 Running 0 
redis-slave-8dhc2 1/1 Running 0 


3.3.4 创建 Redis Slave Service 


创建 Redis Salve Service 来 代理 Redis Salve Pod , 


Service 的 定义 文件 redis- slave-service.yaml: 


apiVersion: vi 
kind: Service 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
ports: 
# the port that this service should serve on 
- port: 6379 
selector: 


name: redis-slave 


AGE 


24s 


24s 


Redis Salve 


通过 定义 文件 创建 Redis Salve Service: 


$ kubectl create -f redis-slave-service.yaml 


service "redis-slave" created 


查询 Redis Salve Service: 


$ kubectl get service redis-slave 


NAME CLUSTER IP EXTERNAL IP PORT(S) 
SELECTOR AGE 

redis-slave 10.254.108.203 «none» 6379/TCP 
name-redis-slave 4S 


3.4 ”运行 Frontend 


3.4.1 创建 Frontend Pod 


通过 Frontend Replication Controller? 8| & Frontend Pod， 将 创建 3 


个 Frontend Pod 。 


Frontend Replication Controller 的 Æ X. X. 件 frontend- 


controller.yaml: 


apiVersion: vi 
kind: ReplicationController 
metadata: 


name: frontend 


labels: 
name: frontend 
spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: php-redis 
image: gcr.io/google_samples/gb- frontend: v3 
env: 
- name: GET_HOSTS_FROM 
value: dns 
# If your cluster config does not include a dns 
service, then to 
# instead access environment variables to find 
service host 
# info, comment out the 'value: dns' line above, and 
uncomment the 
# line below. 
# value: env 
ports: 


- containerPort: 80 


Frontend Replication Controller 的 定义 中 设置 Pod 副 本 数 为 3，Pod 模 


pz BO 


板 包 含 一 个 容器 ， 容 器 使 用 镜像 gcr.io/google_samples/gb-frontend:v3， 
这 是 一 个 PHP 实 现 的 Web 应 用 ， 人 简单 地 说 将 写 数据 到 Redis Master, 3f 
从 Redis Slave 中 读 取 数据 : 


<? 


set include path('.:/usr/local/lib/php'); 


error reporting(E ALL); 


ini set('display errors', 1); 
require 'Predis/Autoloader.php'; 


PredisNAutoloader::register(); 


if (isset($ GET['cmd']) === true) { 
$host - 'redis-master'; 
if (getenv('GET HOSTS FROM') == 'env') { 


$host - getenv('REDIS MASTER SERVICE HOST'); 
} 
header('Content-Type: application/json'); 
if ($ GET['cmd'] == 'set') { 
$client = new Predis\Client([ 
'scheme' => 'tcp', 
'host' => $host, 


'port' => 6379, 


1); 


$client->set($_GET['key'], $ GET['value']); 


print('("message": "Updated"}'); 


) else ( 
$host - 'redis-slave'; 
if (getenv('GET HOSTS FROM') == 'env') { 
$host = getenv('REDIS SLAVE SERVICE HOST'); 
} 
$client = new PredisNClient([ 
'scheme' => 'tcp', 
"host ' => $host, 
'port' -» 6379, 
1); 
$value = $client-»get($ GET['key']); 
print('{"data": "' . $value . '"}'); 
} 
} else { 
phpinfo(); 
) ?> 


代码 中 是 通过 环境 变量 GET_HOSTS_FROM 来 控制 使 用 环境 变量 


方式 还 是 DNS 方式 来 发 现 Redis Master Server 和 Redis Slave Server 的 。 


提示 


t gcr.io/google_samples/gb-frontend:v3HJDockerfile# 4 : 


https://github.com/kubernetes/kubernetes/tree/vi.1.1/examples 


/guestbook/php-redis 


通过 定义 文件 创建 Frontend Replication Controller: 


$ kubectl create -f frontend-controller.yaml 


replicationcontroller "frontend" created 


创建 成 功 后 ， 查 询 Frontend Replication Controller: 


$ kubectl get replicationcontroller frontend 


CONTROLLER CONTAINER(S) IMAGE(S) 
SELECTOR REPLICAS AGE 
frontend php-redis gcr.io/google samples/gb-frontend:v3 
name-frontend 3 9s 


Frontend Replication Controller@!| 34473 Frontend Pod: 


$ kubectl get pod --selector name-frontend 


NAME READY STATUS RESTARTS AGE 
frontend-1670s 1/1 Running 22s 
frontend-2t6sw 1/1 Running © 21s 
frontend-ehbxc 1/1 Running © 21s 


3.4.2 ”创建 Frontend Service 


f| & Frontend Service{t##Frontend Pod, Frontend ServiceH 4E Y. X 


ft-frontend-service. yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
ports: 
# the port that this service should serve on 
- port: 80 
selector: 


name: frontend 


通过 定义 文件 创建 Frontend Service: 


$ kubectl create -f frontend-service.yaml 


service "frontend" created 


查询 Frontend Service: 


$ kubectl get service frontend 


NAME CLUSTER_IP EXTERNAL_IP 
SELECTOR AGE 
frontend 10.254.69.78 <none> 


name=frontend 22S 


PORT(S) 


80/TCP 


3.5 ”设置 Guestbook 外 网 访问 


至 此 Guestbook 束 已 经 运行 在 Kubernetes 上 ， 但 是 还 有 一 件 很 重要 
的 事情 要 解决 ， 用 户 该 如 何 访问 Guestbook Frontend 呢 ?是 否 通 过 
Frontend Service 的 虚拟 IP 10.254.69.78? 但 是 Service 的 虚拟 人 P 是 由 
Kubernetes 虚 拟 出 来 的 内 部 网 络 ， 而 外 部 网 络 是 无 法 寻 址 到 的 ， 这 时 
候 束 需要 增加 一 层 网 络 转 发 ， 即 外 网 到 内 网 的 转发 。 实 现 方 式 有 很 多 
种 ， 我 们 这 里 采用 一 种 叫 作 NodePort 的 方式 来 实现 。 即 Kubernetes 将 会 
在 每 个 Node 上 设置 端口 ， 称 为 NodePort， 通 过 NodePort 端 口 可 以 访问 
到 Pod。 


修改 Frontend Service 的 定义 文件 frontend-service.yaml ， 设 置 
spec.type 为 NodePort: 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
type: NodePort 
ports: 
# the port that this service should serve on 
- port: 80 
selector: 


name: frontend 


重新 创建 Frontend Service: 


$ kubectl replace -f frontend-service.yaml --force 

You have exposed your service on an external port on all nodes 
in your 

cluster. If you want to expose this service to the external 
internet, you may 

need to set up firewall rules for the service port(s) 


(tcp:31505) to serve traffic. 


See http://releases.k8s.io/release-1.1/docs/user- 
guide/services-firewalls.md for more 
details. 


service "frontend" created 


Frontend Service 创建 成 功 信 息 中 说 明了 已 经 创建 NodePort 
(tcp:31505)， 那 么 通过 任何 一 个 Node 的 IP 和 NodePort (tcp:31505) 即 可 访 
问 到 Guestbook Frontend。 然 后 在 界面 的 输入 框 中 输入 任意 字符 串 并 提 
区 ， 字 符 串 将 会 被 保存 并 显示 在 最 下 方 ， 如 图 3-2 所 示 。 


Guestbook 


Life is good 
Live in the moment 
The world is his who enjoys it 


图 3-2” Guestbook 界面 


3.6 ”清理 Guestbook 


清理 Guestbook， 只 需要 分 别 删 除 创 建 出 的 Replication Controller 和 


Service: 


$ kubectl delete replicationcontroller redis-master redis-slave 
frontend 

replicationcontroller "redis-master" deleted 
replicationcontroller "redis-slave" deleted 


replicationcontroller "frontend" deleted 


$ kubectl delete service redis-master redis-slave frontend 
service "redis-master" deleted 
service "redis-slave" deleted 


service "frontend" deleted 


第 4 章 
Pod 


Pod 是 Kubernetes 的 基本 操作 单元 ， 也 是 应 用 运行 的 载体 。 
Kubernetes 系 统 都 是 围绕 着 Pod 展 开 的 ， 比 如 如 何 部 署 运行 Pod、 ma 
UEPodHY Ay SE PE ` UMA PoE ° 57h, Podzé— T 9x THO SSH 
集合 ， 这 可 以 说 是 一 大 创新 点 ， 提 供 了 一 种 容器 组 合 的 模型 ， 当 然 也 
使 得 在 Pod 的 操作 和 生命 周期 管理 上 稍 有 不 同 。 本 章 将 围绕 Pod 进 行 详 
细 讲 解 ， 首 先 介绍 如 何 运 行 一 个 最 基本 的 Pod， 然 后 由 浅 入 深 地 说 明 
Pod 的 各 个 方面 ， 包 括 资源 隔离 、 网 络 、 生 命 周 期 管理 和 调度 。 


41 国际 惯例 的 Hello World 


不 免 俗 地 我 们 也 将 以 Hello World 作 为 开始 ， 创 建 一 个 简单 的 Hello 
World Pod， 运 行 一 个 输出 “Hello World” 的 容器 ，Hello World Pod 的 定义 
文件 hello-world-pod.yaml: 


apiVersion: vi 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: OnFailure 


containers: 


- name: hello 
image: "ubuntu:14.04" 


command: ["/bin/echo", "Hello", "World" ] 


定义 文件 中 描述 了 Pod 的 属性 和 行为 ， 其 中 的 主要 要 素 如 下 所 示 。 
。apiVersion: 声明 Kubernetes 的 API 版 本 ， 目 前 是 v1 。 

“ kind: 声明 API 对 象 的 类 型 ， 这 里 类 型 是 Pod 。 

e metadata: 设置 Pod 的 元 数据 。 

name: 指定 Pod 的 名 称 ，Pod 名 称 必须 在 Namespace 内 唯一 。 
spec: 配置 Pod 的 具体 规格 。 


。restartPolicy: 设置 Pod 的 重启 案 上 略 。 
e containers: 设置 Pod 中 容器 的 规格 ， 数 组 形式 ， 每 一 项 定义 
一 个 容 妖 。 
name: 指定 容器 的 名 称 ， 在 Pod 的 定义 中 唯一 。 
image: 设置 容器 镜像 。 
command: ix EH BUB 


Hello World Pod 的 定义 中 设置 了 一 个 容 絮 ， 名 称 是 hello， 使 用 镜像 
ubuntu:14.04， 同 时 启动 命令 是 ["/bin/echo","Hello","World"]， 实 际 上 这 
类 似 我 们 使 用 docker run 命 令 运 行 容器 : 


$ docker run --name hellop ubuntu:14.04 /bin/echo Hello World 
Hello World 


需要 注意 的 是 ， 因 为 容器 输出 完 Hello World 就 会 退出 ， 这 是 一 次 
性 执行 的 ， 所 以 在 Pod 的 定义 中 ，.spec.restartPolicy 设 置 为 OnFailure， 
即 在 容器 正常 退出 的 情况 下 不 会 重新 创建 容器 。 


通过 定义 文件 创建 Hello World Pod: 


$ kubectl create -f hello-world-pod.yaml 


pod "hello-world" created 


创建 成 功 后 ， 可 以 查询 Hello World Pod: 


$ kubectl get pod hello-world 
NAME READY STATUS RESTARTS AGE 


hello-world 0/1 ExitCode:0 0 1m 


然后 可 以 查询 Pod 输 出 : 


$ kubectl logs hello-world 
Hello World 


最 后 删除 Hello World Pod: 


$ kubectl delete pod hello-world 
pod "hello-world" deleted 


4.2 ”Pod 的 基本 操作 


4.2.1 创建 Pod 


4.1777 FRIE A kubectl create 命 令 创建 了 Pod，Kubernetes 中 大 部 
分 API 对 象 都 是 通过 kubectl create 命 令 创 建 的 。 


如 果 Pod 的 定义 存在 错误 ，kubectl create 会 打印 错误 信息 ， 现 有 一 
个 Pod 的 错误 定义 文件 error-pod.yaml: 


apiVersion: v1 


kind: Pod 
metadata: 
spec: 


restartPolicy: Maybe 
containers: 
- name: hello 

image: "ubuntu:14.04" 


entrypoint : ["/bin/echo","Hello", "World" ] 


过 定义 文件 创建 Pod， 将 会 创建 失败 并 提示 相应 的 错误 信息 : 


$ kubectl create -f error-pod.yaml 


The Pod "" is invalid. 


* metadata.name: required value, Details: name or generateName 
is required 
* spec.restartPolicy: unsupported value 'Maybe' , Details: 


supported values: Always, OnFailure, Never 


4.2.2 ”查询 Pod 


最 常用 的 查询 命令 就 是 kubectl get， 可 以 查询 一 个 或 者 多 个 Pod 的 
信息 ， 现 在 查询 指定 Pod: 


$ kubectl get pod my-pod 
NAME READY STATUS RESTARTS AGE 


my- pod 1/1 Running 0 10s 


查询 显示 的 字段 含义 如 下 所 示 。 
* NAME: Pod 的 名 称 。 


* READY: Pod 的 准备 状况 ， 右 边 的 数字 表示 Pod 包 含 的 容器 总 数 
目 ， 左 边 的 数字 表示 准备 就 绪 的 容器 数目 。 


* STATUS: Pod 的 状态 。 
。RESTARTS: Pod 的 重启 次 数 。 


e AGE: Pod 的 运行 时 间 。 


其 中 Pod 的 准备 状况 指 的 是 Pod 是 否 准备 束 绪 以 接收 请 求 ，Pod 的 准 
备 状况 取决 于 容器 ， 即 所 有 容器 都 准备 就 绕 了 ，Pod 才 准备 就 绕 。 这 时 
候 Kubernetes 的 代理 服务 才 会 添加 Pod 作 为 分 发 后 端 ， 而 一 旦 Pod 的 准备 
状况 变 为 false (至 少 一 个 容器 的 准备 状况 变 为 false) ，Kubemetes 会 将 
Pod 从 代理 服务 的 分 发 后 端 移 除 ， 即 不 会 分 发 请 求 给 该 Pod。 


默认 情况 下 ，kubectl get 只 是 显示 Pod 的 简要 信息 ， 以 下 方式 可 用 
于 获取 Pod 的 完整 信息 : 


$ kubectl get pod my-pod --output json # 用 JSON 格 式 显示 Pod 的 完整 信 
息 


$ kubectl get pod my-pod --output yaml  # 用 YAML 方 式 显示 Pod 的 完整 信 
息 


另外 ，kubectl get 支 持 以 Go Template 方 式 过 滤 出 指定 的 信息 ， 比 如 
查询 Pod 的 运行 状态 : 


$ kubectl get pods my-pod --output=go-template  --template- 
{{.status.phase}} 


Running 


—^ fit 4 kubectl describe 支 持 查 询 Pod 的 状态 和 生命 周期 事件 : 


J 


$ kubectl describe pod my-pod 
Name: my -pod 

Namespace: default 

Image(s): nginx 

Node: kube-node-2/192.168.3.148 


Start Time: Sun, 22 Nov 2015 18:00:34 +0800 


Labels: <none> 
Status: Running 
Reason: 

Message: 

IP: 10.0.62.37 


Replication Controllers: <none> 
Containers: 
container1: 


Container ID: 


docker://60387df7e5f2c781ed508084ffa3579f05482c6b465abb3dAfcaeO0a 


de064b813 
Image: nginx 


Image ID: 


docker://6886fb5a9b8d73b12d842bab8f9a6941c36094c2974abddb685d54c 


9d99e37da 
State: Running 
Started: Sun, 22 Nov 2015 18:00:42 +0800 
Ready: True 
Restart Count: 0 
Environment Variables: 
Conditions: 
Type Status 
Ready True 


Volumes: 


Events: 


查询 显示 的 字段 舍 义 如 下 所 示 。 
。Name: Pod 的 名 称 。 

* Namespace: Pod 的 Namespace。 
。Image(s): Pod 使 用 的 镜像 。 


e Node: Pod 所 在 的 Node。 


* Start Time: Pod 的 起 始 时 间 。 

e Labels: Pod 的 Label。 

。Status: Pod 的 状态 。 

* Reason: Pod 处 于 当前 状态 的 原因 。 

e Message: Pod 处 于 当前 状态 的 信息 。 

° IP: Pod 的 PodIP ° 

* Replication Controllers: Pod 对 应 的 Replication Controller ° 
e Containers: Pod 中 容器 的 信息 。 


Bx Be 


* Container ID: ##sHID ° 

*Image: 容 需 的 镜像 。 

。Image ID: 镜像 的 ID 。 

* State: 容器 的 状态 。 

。Ready: 容器 的 准备 状况 (true 表 示 准 备 就 绪 ) 。 
* Restart Count: 容 絮 的 重启 次 数 统计 。 

* Environment Variables: 容器 的 环境 变量 。 


e Conditions: Pod 的 条 件 ， 包 含 Pod 的 准备 状况 (true nits kt 
绪 ) 。 


e Volumes: Pod 的 数据 卷 。 
。Events: 与 Pod 相 关 的 事件 列表 。 


4.233 ”删除 Pod 


可 以 通过 kubectl delete 命 令 删 除 Pod: 
$ kubectl delete pod my-pod 
另外 ，kubectl delete 命 令 可 以 批量 删除 全 部 Pod: 


$ kubectl delete pod --all 


4.2.4 iPod 


Pod 在 创建 之 后 如 果 和 希望 更 新 Pod， 可 以 在 修改 Pod 的 定义 文件 后 执 


dus 


$ kubectl replace /path/to/my-pod.yaml 


(RAE ALA PodB IR Ze JS EXE INABA, CORA aR, IIR 
可 以 通过 kubectl replace 命 令 设置 --force 参 数 ， 等 效 于 重建 Pod 。 


43 “Pod 与 容器 


在 Docker 中 ， 容 器 是 最 小 处 理 单位 ， 增 删改 查 的 对 象 是 容器 ， 容 
器 是 一 种 虚拟 化 技术 ， 容 器 之 间 是 隔离 的 ， 隔 离 是 基于 Linux 
Namespace 实 现 的 ，Linux 内 核 中 提供 了 6 种 Linux Namespace 陋 离 的 系统 
调用 ， 如 表 4-1 所 示 。 


324-1 Linux Namespace 


Linux Namespace 系统 调用 参数 隔离 内 容 

CLONE_NEWUTS 主机 名 与 域名 
CLONE_NEWIPC 音 号 量 、 消 息 队 列 和 共享 内 存 
CLONE_NEWPID 进程 编号 

Network CLONE_NEWNET 网 络 设备 、 网 络 栈 、 端 口 等 
Mount CLONE_NEWNS ERI OURA) 

User CLONE_NEWUSER JAFHA 2H 
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为 是 容 需 的 一 种 延伸 扩展 ， 一 个 Pod 也 是 一 个 隔离 体 ， 而 Pod 包 含 的 一 
组 容器 又 是 共享 的 〈 当 前 共享 的 Linux Namespace 包 括 : PID ^ 
Network、IPC 和 UTS) 。 除 此 之 外 ，Pod 中 的 容器 可 以 访问 共同 的 数据 
卷 来 实现 文件 系统 的 共享 ， 所 以 Kubernetes 中 的 数据 卷 是 Pod 级 别 的 ， 
而 不 是 容 髓 级 别 的 。 


Pod 是 容 右 的 集合 ， 容 占 是 真正 的 执行 体 。 相 比 原生 的 容 右 接口 ， 
Pod 提 供 了 更 高 层次 的 抽象 ， 但 是 Pod 的 设计 并 不 是 为 了 运行 同一 个 应 
用 的 多 个 实例 ， 而 是 运行 一 个 应 用 多 个 紧密 联系 的 程序 。 而 每 个 程序 
运行 在 单独 的 容 需 中 ， 以 Pod 的 形式 组 合成 一 个 应 用 。 相 比 于 在 单个 容 
器 中 运行 多 个 程序 ， 这 样 的 设计 有 以 下 好 处 。 


“ 透明 性 : 将 Pod 内 的 容器 向 基础 设施 可 见 ， 育 层 系统 就 能 向 容器 
提供 如 进程 管理 和 资源 监控 等 服务 ， 这 样 能 给 用 户 市 来 极 大 便利 。 


- 解 绑 软 件 的 依赖 : 这 样 单个 容 只 可 以 独立 地 重建 和 重新 部 署 ， 可 
以 实现 独立 容器 的 实时 更 新 。 


“ 易 用 性 : 用 户 不 需要 运行 自己 的 进程 管理 器 ， 也 不 需 负责 信号 量 
和 退出 码 的 传递 等 。 


高 效 性 : 因为 底层 设备 负责 更 多 的 管理 ， 容 器 因而 能 更 轻 量 化 。 


p P MIRRA JEH docker 
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18 ° zl ecc E 如 采 镜 像 不 人 存在， 会 从 
Docker 镜 像 仓库 下 载 。Kubernetes 中 可 以 选择 镜像 的 下 载 策略 ， 文 持 的 
策略 如 下 。 


e Always: 每 次 都 下 载 最 新 的 镜像 。 
e Never: 只 使 用 本 地 镜像 ， 从 不 下 载 。 


* IfNotPresent: 只 有 当 本 地 没有 的 时 候 才 下 载 镜 像 。 


Kubernetes Node 是 容 姻 运行 的 答 主 机 ，Pod 被 分 配 到 Node 之 后 ， 会 
根据 镜像 下 载 案 略 选择 是 否 下 载 镜 像 。 有 时 候 网 络 下 载 是 一 个 较 大 的 
开销 ， 可 以 根据 需要 上 自行 选择 策略 ， 但 是 无 论 如 何 要 确保 镜像 在 本 地 
或 者 镜像 仓库 存在 ， 人 否则 Pod 无 法 运行 。 


Pod 定 义 中 一 个 容 船 镜像 的 配置 示例 如 下 所 未 : 


name: hello 
image: "ubuntu:14.04" 


imagePullPolicy: Always 


Docker 镜 像 仓 库 也 称 为 Docker 注 册 服 务 器 (Docker Registry) ， 它 
包括 Docker 公 共 镜 像 仓库 (Docker Hub) 和 私有 镜像 仓库 。 


例如 对 于 ubuntu:14.04， 它 实际 上 等 效 于 dockerio/ubuntu:14.04， 即 
从 Docker 公 共 镜 像 仓 库 下 载 镜 像 。 而 对 于 myregistry.com/ubuntu:14.04 来 
说 ，myregistry.com 是 Docker 私 有 镜像 仓库 地 址 ， 即 从 myregistry.com 下 
载 镜 像 。 


使 用 Docker 私 有 镜像 仓库 ， 往 往 需要 进行 认证 。 一 种 方法 是 在 所 
有 的 Node 上 手工 操作 docker login [registry] 进 行 登录 认证 ; 另 一 种 方法 
是 在 Pod 中 添加 Image Pull Secret H FWE, Image Pull Secret 是 一 种 
kubernetes.io/dockercfg 类 型 的 Secret，Kubernetes 用 来 进行 Docker 镜 像 仓 
库 的 认证 ， 有 具体 操作 方法 如 下 所 示 。 


1. 首先 登 水 Docker 私 有 注册 服务 器 ,例如 myregistry.com: 


$ docker login myregistry.com 

WARNING: The Auth config file is empty 

Username: admin 

Password: 

Email: wlh6666@qq.com 

WARNING: login credentials saved in /root/.dockercfg. 


Login Succeeded 


登录 成 功 后 ，Docker 会 生成 一 个 文件 .dockercfg: 


$ echo $(cat ~/.dockercfg) 
{ "myregistry.com": { "auth":  "d2FlYWRtaw46d2FlQDEyMw--" , 
"email": "wlh6666@qq.com" } } 


2. 使 用 Base64 编 码 .dockercfg 内 容 : 


$ export DOCKER CFG DATA-' cat ~/.dockercfg | base64- 


根据 编码 后 的 内 容 创建 Image Pull Secret 的 定义 文件 : 


$ cat > ./image-pull-secret.yaml <<EOF 
apiVersion: vi 
kind: Secret 
metadata: 
name: myregistrykey 
data: 
.dockercfg: $(DOCKER CFG DATA) 
type: kubernetes.io/dockercfg 


EOF 


通过 定义 文件 创建 Image Pull Secret: 


$ kubectl create -f ./image-pull-secret.yaml 


secret "myregistrykey" created 


SR Jc: TE Pod HY) XE SC FF 38 xf .spec.imagePullSecrets 添加 Image Pull 


Secret: 


apiVersion: vi 

kind: Pod 

metadata: 
name: redis 


spec: 


containers: 
- name: redis 
image: myregistrykey.com/redis 
restartPolicy: Always 
imagePullSecrets: 


- name: myregistrykey 


提示 


系统 管理 员 可 以 设置 全 局 的 Image Pull Secret， 创 建 Pod 的 时 候 


会 目 动 添加 上 Image Pull Secret。 这 样 一 来 束 不 需要 每 个 Pod 显 示 配 
置 ， 可 参考 10.3.3 订 。 


4.3.2 ”启动 命令 


局 动 命令 用 来 说 明 容 右 是 如 何 运 行 的 ， 在 Pod 的 定义 中 可 以 设置 容 
器 启动 命令 和 参数 ，4.1 节 中 的 Hello World Pod 就 对 容器 设置 了 启动 命 
A 
A 


apiVersion: v1 
kind: Pod 
metadata: 

name: hello-world 
spec: 


restartPolicy: Never 


containers: 
- name: hello 
image: "ubuntu:14.04" 


command: ["/bin/echo", "Hello", "World" ] 
BIN, sRHIRIBARB <> t n] LBC A: 


command: ["/bin/echo"] 


args: ["Hello","world"] 


在 使 用 docker run 命 令 运行 容 絮 的 上 时候， 如 果 没 有 指定 容 絮 的 启动 
命令 ， 容 器 则 使 用 Docker 镜 像 默 认 的 启动 命令 。 这 一 般 是 通过 
Dockerfile 中 的 CMD 和 ENTRYPOINT 进 行 设置 的 ， 这 是 非常 容易 混淆 的 
两 个 概念 ， 假 设 镜像 imagel 的 Dockerfile 声 明 CMD 命 令 如 下 : 


ROM ubuntu 


CMD ["echo"] 


$ docker run image1 echo hello 


hello 


男 一 个 镜像 image2 的 Dockerfile 声 明 ENTRYPOINT 命 令 如 下 : 


FROM ubuntu 


ENTRYPOINT ["echo"] 


$ docker run image2 echo hello 


echo hello 


从 示例 中 可 以 看 出 ，CMD 命 令 是 可 窗 盖 的 ，docker run 指 定 的 启动 
命令 会 把 CMD 设 置 的 命令 履 盖 。 而 ENTRYPOINT 设 置 的 命令 只 是 一 个 
口 ，docker run 指 定 的 启动 命令 作为 参数 传递 给 ENTRYPOINT 设 置 的 
命令 ， 而 不 是 进行 奉 换 。 


在 Pod 的 定义 中 ，command 和 args 都 是 可 选项 ， 将 和 Docker 镜 像 的 
ENTRYPOINT 和 CMD 相 互 作 用 ， 生 成 最 终 容 器 的 启动 命令 ， 有 具体 规则 
如 下 所 示 : 


- Ol ZR ZW YA TBE command Fil args, M A ae fi Hj BRAY 
ENTRYPOINT 和 CMD 作 为 启动 命令 运行 。 


。 如 果 容 器 指定 了 command， 而 没有 指定 args， 则 容 右 名 略 镜像 的 
ENTRYPOINT 和 CMD， 使 用 指定 的 command 作 为 启动 命令 运行 。 


。 如 果 容 磊 没 有 指定 command， 只 是 指定 了 args， 容 姨 将 使 用 镜像 
的 ENTRYPOINT 和 和 CMD 作为 启动 命令 运行 。 


。 如 果 容 器 指定 了 command 和 args， 则 容器 使 用 command 和 和 args 作 为 


启动 命令 运行 。 


表 4-2 枚 举 了 4 条 规则 的 相应 示例 。 


镜像 ENTRYPOINT | 镜像 CMD 容器 command 容器 args 最 终 启动 命令 
[/ep-1] [foo bar] NULL NULL [ep-1 foo bar] 
[/ep-1] [foo bar] [/ep-2] NULL [ep-2] 

[/ep-1] [foo bar] <not set> [zoo boo] [ep-1 zoo boo] 
[/ep-1] [foo bar] <not set> [zoo boo] [ep-2 zoo boo] 


43.3 “环境 变量 


Pod 定 义 中 可 以 设置 容器 运行 时 的 环境 变量 : 


env: 

- name: PARAMETER_1 
value: value_1 

- name: PARAMETER_2 


value: value_2 


对 于 Hello World Pod， 可 以 通过 设置 环境 变量 的 方式 进行 改造 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: Never 
containers: 
- name: hello 
image: "ubuntu:14.04" 
env: 


- name: MESSAGE 


value: "hello world" 
command: ["/bin/sh", "-c"] 


args: ["/bin/echo \"${MESSAGE}\"" ] 


Eaa P, Pod Pi Aarts BRAS, Ce UIPodB s 
称 、Pod 所 在 的 Namespace 等 。 在 Kubernetes 中 提供 了 Downward API 获 
取 这 些 信 息 ， 并 且 可 以 通过 环境 变量 告诉 容器 目前 支持 的 信息 。 


。Pod 的 名 称 : metadata.name ° 
。Pod 的 Namespace: metadata.namespace ° 


。Pod 的 PodIP:，status.podIP。 


现在 创建 一 个 Pod 并 通过 环境 变量 来 获取 Downward API，Pod 的 定 
义 文 件 downwardapi- env.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: downwardapi-env 
spec: 
containers: 

- name: test-container 
image: ubuntu:14.04 
command: ["/bin/bash","-c","while true; do sleep 5; done" 
env: 

- name: MY_POD_NAME 


valueFrom: 


fieldRef: 
fieldPath: metadata.name 
- name: MY POD NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
- name: MY POD IP 
valueFrom: 
fieldRef: 


fieldPath: status.podIP 


PodÊ EA T, APh, Wie Ac RAs MAE ee: 


$ kubectl exec downwardapi-env env|grep MY POD 
MY POD NAME-downwardapi-env 

MY POD NAMESPACE-default 

MY POD IP-10.0.10.103 


4.3.4 端口 


在 使 用 docker run 运 行 容 器 的 时 候 往 往 通过 --publish/-p 参 数 设置 端 
口 映 射 规则 ， 同 样 的 ， : PAXEPodBJ AE X. Fi BA a RTO , 
比如 下 面 这 个 Pod 的 设置 容器 nginx 的 端口 映射 规则 为 0.0.0.0:80- 
>80/TCP: 


apiVersion: vi 


kind: Pod 


metadata: 

name: my-nginx 

spec: 

containers: 

- name: nginx 
image: nginx 
ports: 

- name: web 
containerPort: 80 
protocol: TCP 
hostIP: 0.0.0.0 


hostPort: 80 


在 Pod 的 定义 中 ， 通 过 .spec.containers[].ports[] 设 置 容器 的 端口 ， 数 
组 形式 ， 每 一 项 的 参数 如 下 所 示 。 


*name: 设置 端口 名 称 ， 必 须 在 Pod 内 唯一 ， 当 只 配置 一 个 端口 的 
时 候 ， 这 是 一 个 可 选项 ， 当 配置 多 个 端口 的 时 候 ， 这 是 一 个 必 选 项 。 


e containerPort: 必 选 项 ， 设 置 在 容器 内 的 端口 ， 有效 值 范围 为 
0~65536 (不 包括 0 和 65536) 。 


e protocol: 可 选项 ， 设 置 端 口 的 协议 ，TCP 或 者 UDP， 默 认 是 
TCP ° 


ehostIP: P ÆT, RET EVEAIP, MUREA By RB 
IP 接 口上 ， 即 0.0.0.0 » 


* hostPort: 可 选项 ， 设 置 在 宿主 机 上 的 端口 ， 如 果 设 置 则 进行 端 
口 映 射 ， 有 效 值 范围 为 0~ 65536 (不 包括 0 和 65536) ° 


使 用 簿 主机 端口 需要 考虑 端口 冲突 问题 ， 幸 运 的 是 ，Kubernetes 在 
调度 Pod 的 时 候 ， 会 检查 宿主 机 端口 是 否 神 突 。 比 如 两 个 Pod 都 需要 使 
用 得 主机 端口 80， 那 么 调度 的 时 候 就 会 将 这 两 个 Pod 调 度 到 不 同 Node 
上 。 不 过 ， 如 果 所 有 Node 的 端口 都 被 占用 了 ， 那 么 Pod 调 度 会 失败 。 


4.3.5 “数据 持久 化 和 共享 


容 郁 是 临时 存在 的 ， 如 采 容 需 被 销 驱 ， 容 天 中 的 数据 将 会 丢失 。 
为 了 能 够 持久 化 数据 以 及 共享 容器 间 的 数据 ，Docker 提 出 了 数据 卷 
(Volume) 的 概念 。 简 单 来 说 ， 数 据 卷 就 是 目录 或 者 文件 ， 它 可 以 绕 
过 默认 的 联合 文件 系统 ， 而 以 正常 的 文件 或 者 目录 的 形式 存在 于 宿主 
lee 


在 使 用 docker run 运 行 容 如 的 上 时候， 我 们 经 常 使 用 参数 --volume/-v 
创建 数据 卷 ， 即 将 窒 主 机 上 的 目录 或 者 文件 挂 载 到 容器 中 。 即 使 容器 
被 销毁 ， 数 据 卷 中 的 数据 仍然 保存 在 答 主 机 上 。 


一 方面 ， 在 Kubermnetes 中 对 Docker 数 据 卷 进行 了 扩展 ， 支 持 对 接 第 
三 方 存储 系统 。 男 一 方面 ，Kubernetes 中 的 数据 卷 是 Pod 级 别 的 ，Pod 中 
的 容器 可 以 访问 共同 的 数据 卷 ， 实 现 容器 间 的 数据 共享 。 


我 们 再 次 对 Hello World Pod 进 行 改造 。 在 Pod 中 声明 创建 数据 卷 ， 
Pod 中 的 两 个 容器 将 共享 数据 卷 ， 容 器 write 写 入 数据 ， 容 器 hello 读 出 数 
据 ，Hello World Pod 的 定义 文件 hello-world-pod.yaml: 


apiVersion: vi 
kind: Pod 
metadata: 
name: hello-world 
spec: 
restartPolicy: Never 
containers: 
- name: write 
image: "ubuntu:14.04" 
command: ["bash","-c","echo \"Hello World\" >> /data/hello"] 
volumeMounts: 
- name: data 
mountPath: /data 
- name: hello 
image: "ubuntu:14.04" 
command: ["bash", "-c","sleep 10; cat /data/hello"] 
volumeMounts: 
- name: data 
mountPath: /data 
volumes: 
- name: data 
hostPath: 


path: /tmp 


可 以 看 到 在 Pod 定 义 中 ，.spec.volumes 配 置 了 一 个 名 称 为 data 的 数 
据 卷 ， 数 据 卷 的 类 型 是 hostPath， 使 用 窒 主 机 的 目录 /tmp。Pod 中 的 两 个 
容 絮 都 通过 .spec.containers[]. VolumeMounts 来 设置 挂 载 数 据 卷 到 容 絮 中 


的 路 径 /data。 容 器 write 将 往 /data/hello 写 入 “Hello World”， 容 器 hello 等 
待 一 会 儿 ， 然 后 读 取 文件 /data/hello 的 数据 显示 ， 即 输出 “Hello 
World” ° 这样 一 来 束 实 现 了 两 个 容器 的 数据 共享 。Kubernetes 数 据 卷 提 
供 了 非常 丰富 的 持久 化 文 持 ， 详 情 可 参考 7.3 季 。 


44 Pod 的 网 络 


Pod 中 的 所 有 容器 网 络 都 是 共享 的 ， 一 个 Pod 中 的 所 有 容器 中 的 网 
络 是 一 致 的 ， 它 们 能 够 通过 本 地 地 址 (localhost) 访问 其 他 用 户 容器 的 
端口 。 


在 Kubernetes 网 络 模型 中 ， 每 一 个 Pod 都 拥有 一 个 扁平 化 共享 网 络 
命名 空间 的 卫 ， 称 为 PodIP。 通 过 PodIP ，Pod 就 能 够 跨 网 络 与 其 他 物理 
NLA ALAS ETT IE Bo 


在 Pod 运 行 后 ， 我 们 可 以 查询 Pod 的 PodIP: 


$ kubectl get pod my-app --template={{.status.podIP}} 
10.0.10.204 


这 是 一 个 10.0.10.0/24 网 段 的 P， 实 际 上 这 是 由 Docker 为 容 絮 进行 网 
络 虚拟 化 隔离 而 分 配 的 内 部 IP。 也 可 以 设置 Pod 为 Host 网 络 模式 ， 即 直 
接 使 用 宿主 机 的 网 络 ， 不 进行 网 络 虚 拟 化 隔离 。 这 样 一 来 ，Pod 中 的 所 
有 容器 就 直接 暴露 在 宿主 机 的 网 络 环境 中 ， 这 时 候 ，Pod 的 PodIP 就 是 
其 所 在 Node 的 IP 。 


下 面 定 义 的 Pod 设 置 为 Host 网 络 模式 (.spec.hostNetwork-true) : 


apiVersion: vi 
kind: Pod 
metadata: 

name: my-app 

spec: 

containers: 

- name: app 
image: nginx 
ports: 

- name: web 
containerPort: 80 
protocol: tcp 


hostNetwork: true 


使 用 Host 网 络 模式 需要 特别 注意 ， 一 方面 ， 因 为 不 存在 网 络 隔 
B BAR Em, 另 一 方面 ，Pod 可 以 直接 访问 和 宿主 机 上 的 所 有 
网 络 设备 和 服务 ， 从 安全 性 上 来 说 这 是 不 可 控 的 。 


4.5 ”Pod 的 重启 策略 


Pod 的 重 局 策略 指 的 是 当 Pod 中 的 容 夯 终止 退出 后 ， 重 局 容 需 的 富 
略 。 需 要 注意 的 是， 因为 Docker 容 器 的 轻 量 " E Je Eg B BE SK bn 
上 是 直接 重建 容器 ， 所 以 容器 中 的 数据 将 会 丢失 ， 如 有 需要 持久 化 的 
数据 ， 那 么 需要 使 用 数据 卷 进行 持久 化 设置 。 


重启 策略 是 通过 Pod 定 义 中 的 .spec.restartPolicy 进 行 设置 的 ， 目 前 
支持 以 下 3 种 集 略 。 


。Always: SAas4 bikie, Bebe Aas, AARI ° 


-OnFailue: 当 容 器 终止 异常 退出 (退出 码 非 0) 时 ， 才 重启 容 


Never: 当 容 器 终止 退出 时 ， 从 不 重启 容器 。 


现在 创建 一 个 pod， 其 中 的 容器 将 异常 退出 (exit 1) ， 而 Pod 的 重 
局 策略 为 OnFailure，Pod 的 定义 文件 on-failure-restart-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: on-failure-restart-pod 
spec: 
containers: 
- name: container 
image: ubuntu:14.04 
command: ["bash","-c", "exit 1"] 


restartPolicy: OnFailure 


通过 定义 文件 创建 Pod: 


$ kubectl create -f on-failure-restart-pod.yaml 


pods/on-failure-restart-pod 


Pod 创 建成 功 后 ， 一 段 时 间 后 查询 Pod: 


$ kubectl get pod on-failure-restart-pod 
NAME READY STATUS RESTARTS AGE 


on-failure-restart-pod 0/1 Error 3 2m 


在 Pod 的 查询 信息 中 ， 属 性 RESTARTS 的 值 为 3， 说 明 Pod 中 的 容器 
已 经 重启 ， 可 以 分 别 查询 每 个 容器 的 重启 次 数 : 


$ kubectl get pod on-failure-restart-pod \ 
--template="{{range .status.containerStatuses}}{{.name}}: 
{{.restartCount}}{{end}}" 


container:3 


提示 


关于 Pod 中 容 恬 的 重 局 次 数 统计 ， 实 际 上 并 不 是 非常 精确 ， 只 
能 作为 一 个 参考 。 首 先 它 获取 Pod 所 在 Node 的 所 有 容器 (包括 运行 
^E 


和 停止 的 ) 作为 统计 基数 ， 所 以 如 果 将 退出 容器 进行 清理 (可 能 
人 工 删除 ， 另 外 Kubelet 会 根据 配置 定时 进行 清理 ) ， 将 会 减少 统计 
的 基数 。 


4.6 ”Pod 的 状态 和 生命 周期 


4.6.1 ”容器 状态 


Pod 的 本 质 是 一 组 容器 ，Pod 的 状态 便 是 容器 状态 的 体现 和 概括 ， 
同时 容 右 的 状态 变化 会 影响 Pod 的 状态 变化 ， 触 发 Pod 的 生命 周期 阶段 


转换 。 


在 使 用 docker run 运 行 容 强 的 时 候 ， 自 和 完 会 下 载 容 器 镜像 。 下 载 成 
a uA 当 容 器 运行 结束 退出 后 (包括 正常 和 异常 退出 ) ， 
句 终 止 ， 这 是 一 个 容器 的 生命 周期 过 程 。 相 应 的 ， c ie 
arte 行 了 状态 的 记录 ， 其 中 每 种 状态 下 包含 的 信息 如 下 所 
Fo 


e Waiting: 容器 正在 等 竺 创建 ， 比 如 正在 下 载 镜像 。 
e Reason: 等 待 的 原因 。 

。Running: 容器 已 经 创建 ， 并 且 正 在 运行 
*startedAt: 容器 创建 时 间 。 


e Terminated: ZAA ILIR HI ° 


e signal: RANEH ° 

e reason: Aas RH IRE e 

* message: 容器 退出 信息 。 
e startedAt: 容器 创建 时 间 。 
e finishedAt: ZEE HIR] e 
e containerID: ASAID ° 


e exitCode: 退出 码 。 


Pod 运 行 后 ， 可 以 查询 其 中 容器 的 状态 : 


$ kubectl describe pod my-pod 


Containers: 
container 1: 


Container ID: 


docker://60387df7e5f2c781ed508084ffa3579f05482c6b465abb3dAfcaeO0a 
de064b813 
Image: nginx 


Image ID: 


docker://6886fb5a9b8d73b12d842bab8f9a6941c36094c2974abddb685d54c 
9d99e37da 
State: Running 
Started: Sun, 22 Nov 2015 18:00:42 +0800 
Ready: True 
Restart Count: 0 


Environment Variables: 


4.6.2 ”Pod 的 生命 周期 阶段 


Pod 的 生命 周期 可 以 简单 描述 为 : 首先 Pod 被 创建 ， 紧 接着 Pod 被 调 
度 到 Node 进 行 部 署 运行 。Pod 是 非常 定 诚 的 ， 一 旦 被 分 配 到 Node 后 ， 
束 不 会 离开 这 个 Node， 直 到 它 家 删除 ， 生 命 周期 完结 。 


Pod 的 生命 周期 被 定义 为 以 下 几 个 阶段 。 


Pending: Pod 已 经 被 创建 ， 但 是 一 个 或 者 多 个 容器 还 未 创建 ， 这 
包括 Pod 调 度 阶段 ， 以 及 容器 镜像 的 下 载 过 程 。 


*Running: Pod 已 经 被 调度 到 Node， 所 有 容器 已 经 创建 ， 并 且 至 少 
一 个 容 右 在 运行 或 者 正在 重 局 。 


e Succeeded: Pod 中 所 有 容器 正常 退出 。 
。Failed: Pod 中 所 有 容 絮 退出 ， 至 少 有 一 个 容 磊 是 一 次 退出 的 。 
可 以 查询 Pod 处 于 生命 周期 的 哪个 阶段 : 


$ kubectl get pods my-app --template="{{.status.phase}}" 


Running 


Pod 被 创建 成 功 后 ， 首 先 会 进入 Pending 阶 段 ， 然 后 被 调度 到 Node 
后 运行 ， 进 入 Running 阶 段 。 如果 Pod 中 的 容器 停止 (正常 或 者 异常 退 
出 ) ， 那 么 Pod 根 据 重 启 策略 的 不 同 会 进入 不 同 的 阶段 ， 举 例如 下 。 


* PodzéRunningDTEz, &'&—^ ZR, RAE OE: 


JR HA RES Always, JSAS HI Aas, Podtei Runing 
阶段 。 

如 果 重 启 策略 是 OnFailure，Pod 进 入 Succeeded 阶 段 。 

如 果 重 局 策略 是 Never，Pod 进 入 Succeeded 阶 段 。 


* PodzéRunningDTEz, &'—^ s, TESRERÜIBOERG: 


WR HARE Always, PASH as, Podi ff Runing 
阶段 。 
如 果 重 启 集 略 是 OnFailure，Pod 保 持 Running 阶 段 。 


TIR A eg Never, Podi A Failed[yT EX ° 
。Pod 是 Running 阶 段 ， 含 有 两 个 容 絮 ， 其 中 一 个 容 絮 异常 退出 : 


JR EA RES Always, JSAS HI Aas, Podtef Runing 
阶段 。 

如 果 重 启 集 略 是 OnFailure，Pod 保 持 Running 阶 段 。 

如 果 重 启 案 略 是 Never，Pod 保 持 Running 阶 段 。 


e Pod 征 Running 阶 段 ， 含 有 两 个 容 郁 ， 两 个 容 需 都 异 币 退 出 : 


UREN R Always, JSAS mss, Podtri Runing 
阶段 。 

QR HA NE xOnFailure, PodtRi Runing Ez ° 

如 果 重 启 案 略 是 Never，Pod 进 入 Failed 阶 段 。 


一 旦 被 分 配 到 Node，Pod 束 不 会 离开 这 个 Node， 直 到 被 删除 。 删 
除 可 能 是 人 为 地 删除 ， 或 者 被 Replication Controller 删 除 ， 也 有 可 能 是 
当 Pod 进 入 Succeeded 或 者 Failed 阶 段 过 期 ， 被 Kubernetes 清 理 反 。 总 之 
Pod 被 删除 后 ，Pod 的 生命 周期 束 算 结束 ， 即 使 被 Replication Controller 
进行 重建 ， 那 也 是 新 的 Pod， 因 为 Pod 的 ID 已 经 发 生 了 变化 ， 所 以 实际 
上 Pod 迁 移 ， 准 确 的 说 法 是 在 新 的 Node 上 重建 Pod 。 


4.6.3 ”生命 周期 回调 函数 


Kubernetes 提 供 了 回调 函数 ， 在 容器 的 生命 周期 的 特定 阶段 执行 调 
用 ， 比 如 容器 在 停止 前 希望 执行 某 项 操作 ， 束 可 以 注册 相应 的 钩子 函 
数 。 目 前 提供 的 生命 周期 回调 函数 如 下 所 示 。 


*PostStart， 在 容器 创建 成 功 后 调用 该 回调 函数 。 
e PreStop: 在 容 硕 被 终止 前 调用 该 回调 函数 。 


钩子 函数 的 实现 方式 有 以 下 两 种 。 


e Exec 
说 明 

在 容 屁 中 执行 指定 的 命令 。 
配置 参数 


command: 需要 执行 的 命令 ， 字 符 溃 数组 。 
示例 


exec: 
command: 
- cat 


- /tmp/health 


e HTTP 


说 明 


发 起 一 个 HTTP 调 用 请 求 。 
配置 参数 
path: 请 求 的 URL 路 径 ， 可 选项 。 
port: 请 求 的 端口 ， 必 选项 。 
host: KASIP, PT, SAY EPodHJPodIP 。 
scheme: 请 求 的 协议 ， 可 选项 ， 默 认 是 HTTP e 
示例 


httpGet: 
host: 192.168.1.1 
path: /notify 
port: 8080 


现在 定义 一 个 Pod， 包 含 一 个 Java 的 Web 应 用 容器 ， 其 中 设置 了 
PostStart 和 PreStop 回 调 函 数 。 即 在 容器 创建 成 功 后 ， 复 制 /sample.war 
F| app H 3& * m XE A as MA IE Z B. KR IK HTTP if cK Fl 
http://monitor.com:8080/warning， 往 监控 系统 发 送 一 个 警告 ，Pod 的 定义 
如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: javaweb-2 


spec: 


containers: 
- image: resouer/sample:v2 
name: war 
lifecycle: 
postStart: 
exec: 
command: 
- "cp" 
- "/sample.war" 
- "Zapp" 
preStop: 
httpGet: 
host: monitor.com 
path: /warning 
port: 8080 


scheme: HTTP 
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WT Pode a EE, Bl Pod PH Aare NE. SATE PB Rete 
Base OIE BIST o (HAN IRA ae IE SITARA ER, BAT 
能 应 用 的 进程 已 经 阻塞 住 无 法 正 利 处 理 请 求 ， 所 以 为 了 提供 更 加 健壮 
的 应 用 ， 往 往 需要 定制 化 的 健康 检查 


除 此 之 外 ， 有 的 应 用 启动 后 需要 进行 一 系列 初始 化 处 理 ， 在 初始 
化 完成 之 前 应 用 是 无 法 正常 处 理 请 求 的 。 如 果 应 用 初始 化 需要 较 长 时 
间 ， 而 实际 上 容器 创建 的 时 间 是 可 以 忽略 不 计 的 。 默 认 情 况 下 ， 


Kubernetes 发 现 容 器 创建 成 功 并 运行 ， 束 会 认为 其 准备 束 绪 ， 真 实情 况 
征 容 船 里 的 应 用 可 能 还 处 于 初始 化 阶段 ， 无 法 正 币 接受 请 求 。 如 采用 
户 访问 融会 得 到 错误 响应 ， 这 不 是 我 们 布 望 看 到 的 情况 。 同 样 的 ， 我 
们 需要 更 加 精确 的 检查 机 制 来 判断 Pod 和 容器 是 否 准备 就 绪 ， 从 而 让 


Kubernetes 判 断 是 否 分 发 请 求 给 Pod 。 


针对 这 些 需求 ，Kubernetes 中 提供 了 Probe 机 制 ， 有 以 下 两 种 类 型 
的 Probe ° 


。Liveness Probe: 用 于 容器 的 目 定义 健康 检查 ， 如 果 Liveness Probe 
检查 失败 ，Kubernetes 将 杀 死 容 絮 ， 然 后 根据 Pod 的 重启 策略 来 决定 是 
T EIER 


e Readiness Probe: Hj FA aN BE X ES TN DUREE, WR 
Readiness Probef$ £i WW, Kubernetes ff 2:38 Pod MARS (CEN 43 Az Ji vig 
移 除 ， 即 不 会 分 发 请 求 给 该 Pod 。 


Probe 文 持 以 下 三 种 检查 方法 。 


。 ExecAction 


说 明 


在 容 右 中 执行 指定 的 命令 进行 检查 ， 当 命令 执行 成 功 (返回 码 为 
0) ， 检 查 成 功 。 


配置 参数 


command: 检查 的 命令 ， 字 符 串 数组 。 


示例 


exec: 
command: 
- cat 


- /tmp/health 


。 TCPSocketAction 


说 明 


对 于 容 句 中 的 指定 TCP 端 口 进行 检查 ， 
功 。 


配置 参数 
port: 检查 的 TCP 端 口 


示例 


tcpSocket : 
port: 8080 


* HTTPGetAction 


HTCP mO SA, RE 


说 明 

发 生 一 个 HTTP 请 求 ， 当 返回 码 介 于 200~400 之 间 时 ， 
配置 参数 

path: 请 求 的 URI 路 径 ， 可 选项 。 

port: 请 求 的 端口 ， 必 选项 。 

host: 请 求 的 IP， 可 选项 ， 默 认 是 Pod 的 PodIP。 

scheme: 请 求 的 协议 ， 可 选项 ， 默 认 是 HTTP ° 
示例 


httpGet: 
path: /healthz 


port: 8080 


4.7.1 Pod 的 健康 检查 


定义 一 个 Pod， 使 用 Liveness Probe 通 过 ExecAction 方 式 检查 容 属 的 


健康 状态 ，Pod 的 定义 文件 liveness-exec-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 


name: liveness-exec-pod 


RERI) « 


labels: 
test: liveness 
spec: 
containers: 
- name: liveness 
image: "ubuntu:14.04" 
command: 


- /bin/sh 


- echo ok > /tmp/health; sleep 60; rm -rf /tmp/health; sleep 
600 


livenessProbe: 
exec: 
command: 
- cat 
- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


通过 定义 文件 创建 Pod: 


$ kubectl create -f liveness-exec-pod.yaml 


pod "liveness-exec-pod" created 
Pod 创 建 之 初 运行 正常 : 


$ kubectl get pod liveness-exec-pod 


NAME READY STATUS RESTARTS AGE 


liveness-exec-pod 1/1 Running 0 15s 


过 1 分 钟 以 后 可 以 看 到 Pod 发 生 了 重启 : 


$ kubectl get pod liveness-exec 
NAME READY STATUS RESTARTS AGE 


liveness-exec-pod 1/1 Running 1 1m 


通过 查询 Pod 事 件 可 以 看 到 ，Liveness Probe 检 查 失 败 : 


$ kubectl describe pod liveness-exec-pod|grep Unhealthy 
. Unhealthy  Liveness probe failed: cat: /tmp/health: No such 


file or directory 


4.7. ”Pod 的 准备 状况 检查 


定义 一 个 Pod， 使 用 Readiness Probe 通 过 ExecAction 方 式 检查 容器 
的 准备 状况 ，Pod 的 定义 文件 readiness-exec-pod.yaml: 


apiVersion: vi 
kind: Pod 
metadata: 

labels: 

test: readiness 

name: readiness-exec-pod 
spec: 

containers: 


- name: readiness 


image: "ubuntu:14.04" 
command: 


- /bin/sh 


- echo ok > /tmp/ready; sleep 60; rm -rf /tmp/ready; sleep 
600 
readinessProbe: 
exec: 
command: 
- cat 
- /tmp/ready 
initialDelaySeconds: 15 


timeoutSeconds: 1 


通过 定义 文件 创建 Pod: 


$ kubectl create -f readiness-exec-pod.yaml 


pod "readiness-exec-pod" created 


Pod 创 建 之 初 运行 正常 ， 容 器 全 部 准备 束 绪 : 


$ kubectl get pod readiness-exec 
NAME READY STATUS RESTARTS AGE 


readiness -exec-pod 1/1 Running 0 26S 
过 1 分 钟 以 后 ， 发 现 Pod 的 READY 数 目 变 为 0: 


$ kubectl get pod readiness-exec-pod 


NAME READY STATUS RESTARTS AGE 


readiness -exec-pod 0/1 Running 0 im 


通过 查询 Pod 事 件 可 以 看 到 ，Readiness Probet & KM: 


$ kubectl describe pod readiness-exec|grep Unhealthy 
. Unhealthy Readiness probe failed: cat: /tmp/ready: No such 


file or directory 


4.8 ”调度 Pod 


2: m m 调度 算法 
分 为 两 个 步骤 ， 第 一 步 季 选 出 符合 条 件 的 Node， 第 二 步 选 择 最 优 的 
Node ° 


对 于 所 有 Node， 首 先 Kubernetes 通 过 一 系列 过 滤 函 数 ， 云 除 不 符合 
条 件 的 Node， 当 前 版 本 (Kubernetes X. 支持 的 过 滤 函 数 如 下 所 
未。 


* NoDiskConflict: 检查 Pod 请 来 的 数据 卷 是 否 与 Node 上 已 存在 Pod 
挂 载 的 数据 卷 存 在 冲突 ， 如 果 存 在 冲突 ， 则 过 小 挥 该 Node ° 

* PodFitsResources: 检查 Node 的 可 用 资源 (CPU 和 内存) 是否 满 足 
Pod 的 资源 请 求 。 

e PodFitsPorts: 检查 Pod 设 置 的 HostPorts 在 Node 上 是 否 已 经 被 其 他 
Pod 占 用 。 


。PodFitsHost: 如 果 Pod 设 置 了 NodeName 属 性 ， 则 算 选 出 指定 的 
Node ° 


e PodSelectorMatches: W 52Podix& f NodeSelectork& vt, MITE HE 
符合 的 Node。 


。 CheckNodeLabelPresence : j$ Æ Node X t$ 存在 Kubernetes 
Scheduler 配 置 的 标签 。 


仿 选 出 符合 条 件 的 Node 来 运行 Pod， 如 果 存 在 多 个 符合 条 件 的 
Node， 那 么 需要 选择 出 最 优 的 Node。Kubernetes 中 通过 一 系列 优先 级 函 
数 (Priority Function) 来 评估 出 最 优 Node。 对 于 每 个 Node， 优 先 级 函 
数 给 出 一 个 分 数 : 0~10 〈10 表 示 最 优 ，0 表 示 最 差 ) ， 而 每 个 优先 级 函 
数 设置 有 权重 什 ，Node 的 最 终 分 数 束 是 每 个 优 移 级 函数 给 出 的 分 数 进 
行 加 权 的 和 ， 比 如 有 两 个 优先 级 函数 priorityFunc1 和 priorityFunc2 ^ 
们 的 权重 值 分 别 是 weight1 和 weight2， 那 么 对 于 NodeA 的 最 终 分 数 是 : 


finalScoreNodeA = (weight1i * priorityFunc1) + (weight2 * 


priorityFunc2) 


这 样 一 来 ， 通 过 最 终 分 数 对 Node 进 行 排 序 ， 得 分 最 高 的 Node 即 最 
优 Node。 如 果 存 在 多 个 Node 并 列 第 一 ， 则 随机 选择 一 个 Node 。 


当前 版 本 (Kubernetes v1.1.1) 的 Kubemetes 提 供 的 优先 级 函数 有 如 
Behe 


* LeastRequestedPriority: 优先 选择 有 最 多 可 用 资源 的 Node。 
e CalculateNodeLabelPriority: 优先 选择 含有 指定 Label 的 Node 。 
* BalancedResourceAllocation: 优先 选择 资源 使 用 均衡 的 Node。 


如 何 进 行 Node 选 择 呢 ? 


在 一 些 场景 下 希望 Pod 调 度 到 指定 的 Node 上 ， 比 如 有 的 Node 专 门 
用 于 测试 ，Pod 在 正式 上 线 前 ， 需 要 先 在 测试 的 Node 上 运行 ， 测 试 完成 
再 发 布 到 生产 环境 的 Node 上 运行 。 这 时 候 束 可 以 用 到 Node Selector， 通 
过 Node 的 Label 进 行 选择 。 


查询 所 有 的 Node: 


$ kubectl get node 
NAME LABELS 
STATUS AGE 


kube-node-1 kubernetes.io/hostname-kube-node-1 Ready 8d 
kube-node-2 kubernetes.io/hostname-kube-node-2 Ready 8d 
kube-node-3 kubernetes.io/hostname-kube-node-3 Ready 8d 


目前 共有 3 个 Node， 状 态 都 是 Ready， 并 且 有 一 个 默认 的 Label 
kubernetes.io/hostname， 然 后 为 Node kube-node-1 增 加 新 的 Label: 


$ kubectl label nodes kube-node-1 env=test 


node "kube-node-1" labeled 


在 定义 Pod 的 时 候 通 过 设置 Node Selector (.spec.nodeSelector) 来 
选择 Node，Pod 的 定义 文件 nginx-pod.yaml: 


apiVersion: v1 

kind: Pod 

metadata: 
name: nginx 
labels: 


env: test 


spec: 
containers: 
- name: nginx 
image: nginx 
imagePullPolicy: IfNotPresent 
nodeSelector: 


env: test 


Pod 创 建成 功 后 将 会 被 分 配 到 Node kube-node-1: 


$ kubectl get pod nginx -o wide 
NAME READY STATUS RESTARTS AGE NODE 


nginx 1/1 Running 0 9s kube-node-1 


除了 设置 Node Selector Z 4b, Pod ih FJ DL i 3f Node Name 
(.spec.nodeName) 直接 指定 Node: 


apiVersion: vi 
kind: Pod 
metadata: 

name: nginx 

labels: 

env: test 

spec: 

containers: 

- name: nginx 


image: nginx 


imagePullPolicy: IfNotPresent 


nodeName: kube-node-1 


不 过 还 是 建议 使 用 Node Selector， 因 为 通过 Label 进 行 选择 是 一 种 
弱 绑 定 ， 而 直接 指定 Node Name 是 强 绑 定 ，Node 失 效 时 会 导致 Pod 无 法 
调度 。 


49 ”问题 定位 指南 


Pod 是 应 用 的 承载 体 ， 当 Pod 运 行 异 常 的 时 候 ， 可 能 是 Kubernetes 系 
统 癌 题 ， 也 可 能 是 应 用 本 身 的 问题 ， 那 么 就 需要 提供 足够 的 信息 用 于 
问题 定位 ，Kubernetes 针 对 Pod 提 供 的 事件 记录 、 日 志 查 询 和 远程 调试 
功能 进行 问题 定位 。 


4.9.1 事件 查询 


Kubernetes 从 Pod 的 创建 开始 ， 在 Pod 的 生命 周期 内 会 产生 各 种 事件 


信息 ， 比 如 Pod 完 成 调度 、 下 载 镜像 完成 等 。 在 Pod 运 行 异 常 的 时 候 ， 
通过 排除 相关 事件 可 以 了 解 是 否 是 由 于 Kubernetes 的 原因 导致 Pod 异 
第 


事件 查询 可 以 先 查 询 所 有 的 事件 : 


$ kubectl get event 


然后 再 查询 Pod 相 关 的 事件 : 


$ kubectl describe pod my-pod 


49.2 日 志 查 询 


志 是 一 项 很 重要 的 信息 ， 可 以 用 来 定位 问题 和 显示 应 用 运行 状 
态 。Docker 容 器 可 以 使 用 docker logs 命 令 查 询 日 志 ， 可 以 通过 kubectl 
logs 命 令 查 询 Pod 中 容 姻 的 日 志 。 


现在 要 定义 一 个 Pod， 包 含 两 个 容器 ， 容 器 container1 输 出 一 条 日 志 
然后 正常 退出 (exit 0) ， 容 器 container2 输 出 一 条 日 志 异 常 退 出 (exit 
1) ， 并 且 设 置 Pod 的 重启 策略 是 OnFailure， 即 当 容 器 异常 退出 时 才 进 
行 重启 ，Pod 的 定义 文件 log-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 

name: log-pod 

spec: 

containers: 

- name: container1 
image: ubuntu:14.04 
command: 

- "bash" 

= "pM 

- "echo N'containeri1: ‘date --rfc-3339 ns N"; exit 0" 
- name: container2 


image: ubuntu:14.04 


command: 

= "bash" 

E "2c 

- "echo \"container2: “date --rfc-3339 ns N"; exit 1" 


restartPolicy: OnFailure 


通过 定义 文件 创建 Pod: 


$ kubectl create -f log-pod.yaml 
pod "log-pod" created 


Pod 创 建成 功 后 ， 会 重新 创建 异常 退出 的 容器 container2: 


$ kubectl get pod log-pod 
NAME READY STATUS RESTARTS AGE 
log-pod 0/2 Error 1 19s 


AEDI £i Pod"P PIT E ae) Ho: 


$ kubectl logs log-pod container1 
container1: 2015-11-21 14:52:55.622701243+00:00 


$ kubectl logs log-pod container2 
Pod "log-pod" in namespace "default": container "container2" is 


in waiting state. 


因为 容器 container2 将 会 异常 退出 然后 重建 ， 所 以 将 处 于 异常 状 
， 从 而 查询 不 到 当前 运行 日 志 。 但 是 kubectl logs 可 以 查询 之 前 容器 


(如 果 存 在 的 话 ) 的 日 志 ， 这 对 于 问题 定位 非常 有 帮助 ， 往 往 容 器 停 
止 前 的 日 志 价 值 更 高 ， 获 取 方 法 只 需要 加 上 --previous/-p 参 数 : 


$ kubectl logs log-pod container2 —previous 


container2: 2015-11-21 14:53:37.377629086+00:00 


4.9.3 Pod 的 临终 遗言 


前 面 我 们 提 到 过 容器 停止 前 的 日 志 价 值 更 高 ， 能 够 获取 最 后 的 错 
误 异 常 消 息 、 调 用 栈 等 ， 我 们 可 以 把 这 些 信息 形象 地 称 为 临终 遗言 ， 
临终 遗言 对 于 问题 定位 是 很 有 帮助 的 。 在 Kubernetes 中 为 Pod 提 供 了 一 
个 持久 化 文件 ， 用 来 保存 临终 遗言 。 


DA 


Pod 的 定义 中 通过 .spec.containers[].terminationMessagePath 指 定 在 容 
器 中 的 临终 遗言 日 志文 件 的 路 径 ， 默 认 值 是 /dewtermination-log。 这 个 
文件 在 Pod 的 整个 生命 周期 内 都 会 保存 ， 每 次 新 建 一 个 pod， 都 会 在 宿 
主机 上 创建 一 个 文件 ， 然 后 挂 载 到 Pod 的 容器 中 ， 这 些 文件 不 会 因为 容 
融 的 销毁 而 丢失 ， 所 以 容器 可 以 把 临终 遗言 写 入 这 个 文件 ， 方 便 问 题 
HEFE ° 


现在 创建 一 个 Pod， 其 中 的 容器 将 写 入 临终 遗言 ，Pod 的 定义 文件 


w-message-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 


name: w-message-pod 


spec: 
containers: 
- name: messager 
image: "ubuntu:14.04" 
terminationMessagePath: /dev/termination-log 
command: 
- "bash" 
= hoe" 
- "echo \" date --rfc-3339 ns I was going to die\" >> 


/dev/termination-log;" 


通过 定义 文件 创建 Pod: 


$ kubectl create -f w-message-pod.yaml 


pod "w-message-pod" created 


$ kubectl get pod w-message-pod 
NAME READY STATUS RESTARTS AGE 


w-message- pod 0/1 Running 2 am 


Pod 运 行 后 ， 容 器 将 往 文件 /dewtermination-log 写 入 临终 遗言 ， 然 后 
可 以 进行 查询 : 


$ kubectl get pod w-message-pod \ 
--template="{{range .status.containerStatuses}} 
{{.lastState. terminated .message}}{{end}}" 


2015-11-21 15:11:57.457833141+00:00 I was going to die 


49.4 ”远程 连接 容器 


问题 定位 时 往往 需要 连接 到 应 用 的 运行 环境 进行 操作 ， 相 比 于 传 
统 的 SSH 方 式 ，Docker 提 供 了 docker attach 和 docker exec 两 个 命令 可 以 
连接 容器 进行 操作 。 同 样 的 ，Kubernetes 对 应 地 提供 了 kubectl attach fill 
kubectl exec 两 个 命令 用 来 远程 连接 Pod 中 的 容器 。 


其 中 attach 命 令 使 用 起 来 不 太 方 便 ， 相 比 之 下 ，exec 命 令 则 非常 强 
大 ， 我 们 可 以 使 用 kubectl exec 命 令 远 程 连接 Pod 中 的 容器 运行 命令 (4 
Pod 只 有 一 个 容器 时 ， 不 需要 指定 容器 ) : 


$ kubectl exec my-pod -- date 


Wed Jan 6 18:19:07 CST 2016 


或 者 直接 进入 Pod 的 容器 中 : 


$ kubectl exec -ti my-pod /bin/bash 
[rootQ my-pod /]£ 


提示 


kubectl exec 命 令 需 要 在 Kubernetes Node 上 安装 nsenter。 


5 


Replication Controller 


Replication Controller 是 Kubernetes 中 的 另 一 个 核心 概念 ， 应 用 托管 
在 Kubernetes 之 后 ，Kubernetes 需 要 保证 应 用 能 够 持续 运行 ， 这 是 
Replication Controller 的 工作 内 容 ， 它 会 确保 任何 时 候 Kubernetes 中 有 指 
定数 量 的 Pod 副 本 〈 或 者 称 为 实例 ) 。 在 此 基础 上 ，Replication 
Controller 进 一 步 提 供 了 高 级 特性 ， 比 如 弹性 伸缩 、 滚 动 升级 等 。 本 章 
将 详细 介绍 Replication Controller， 其 中 也 会 涉及 一 些 相 关 的 内 容 。 


5.1 ”持续 运行 的 Pod 


Kubernetes 提 供 Replication Controller 来 管理 Pod， Replication 
Controller 确 保 任 何 时 候 Kubernetes 集 群 中 有 指定 数量 的 Pod 副 本 在 运 
行 。 如 果 少 于 指定 数量 的 Pod 副 本 ，Replication Controller 会 局 动 新 的 
Pod， 反 之 会 杀 死 多 余 的 以 保证 数量 不 变 。 我 们 通过 Replication 
Controller 来 创建 持续 运行 的 Pod，Replication Controller 的 定义 文件 my- 
nginx-rc.yaml 如 下 所 示 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 

name: my-nginx 


spec: 


replicas: 2 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 


- containerPort: 80 


定义 文件 中 描述 了 Replication Controller 的 属性 和 行为 ， 其 中 的 主 
EZ Ul FAAS ° © apiVersion: 声明 Kubernetes 的 API 版 本 ， 目 前 是 


vl° 


* kind: 声明 API 对 象 的 类 型 ， 这 里 的 类 型 是 Replication 


Controller ° 


e metadata: 设置 Replication Controller 的 元 数据 。 


e name: 指定 Replication Controller AJ $% K, $ P D m E 
Namespace N iE — ° 


e spec: fi Replication Controller 的 具体 规格 。 


e replicas: 设置 Replication Controller 控 制 的 Pod 的 副本 数目 。 


e selector: 47 Replication Controller B5] Label Selector X Vt fig 
Pod 的 Label ° 


e template: 设置 Pod 模 板 ， 同 Pod 的 定义 一 致 。 
通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


查询 Replication Controller: 


$ kubectl get replicationcontroller my-nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -nginx nginx nginx app=nginx 2 
14s 


同时 可 以 查询 到 Replication Controller 创 建 的 Pod: 


$ kubectl get pod --selector app=nginx --label-columns app 


NAME READY STATUS RESTARTS AGE APP 
my-nginx-14lrs 1/1 Running 0 A2s nginx 
my-nginx-cz2gd 1/1 Running 0 42S nginx 


J Replication Controller 设 置 Pod 的 副本 数目 (.spec.replicas) 为 
2， 所 以 创建 出 两 个 Pod， 并 且 可 以 看 出 Pod 的 名 称 前 级 是 Replication 
Controller 的 名 称 ， 后 级 则 是 5 位 随机 字符 串 。 


现在 删除 一 个 Pod: 


$ kubectl delete pod my-nginx-14lrs 


pod "my-nginx-14lrs" deleted 


马上 可 以 看 到 一 个 新 的 Pod 被 创建 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 
my-nginx-cz2gd 1/1 Running 0 2m 
my-nginx-vc43t 1/1 Running 0 29s 


最 后 删除 Replication Controller: 


$ kubectl delete rc my-nginx 


replicationcontroller "my-nginx" deleted 


相应 的 Pod 也 会 被 删除 


$ kubectl get pods --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


使 用 kubectl delete fy < W bR Replication Controller, EA 3A S HR 
Replication Controller 关 联 的 所 有 Pod 副 本 。 如 果 需 要 保留 Pod 运 行 ， 删 
除 Replication Controller 的 时 候 可 以 设置 参数 --cascade=false ° 


除了 kubectl create 命 令 之 外 ， 也 可 以 通过 kubectl run 命 令 创 建 
Replication Controller， 下 面 的 命令 将 创建 名 称 为 my-nginx 的 Replication 
Controller， 创 建成 功 返 回 Replication Controller 的 信息 : 


$ kubectl run my-nginx --image nginx --replicas 2 --labels 


app=nginx 


replicationcontroller "my-nginx" created 


5.2 Pod 模 板 


在 实际 操作 中 ， 相 比 于 直接 创建 Pod， 一 般 都 是 在 Replication 
Controller 中 预先 定义 Pod 模 板 ， 通 过 Replication Controller 来 创建 Pod ° 


Pod 模 板 是 在 Replication Controller 的 定义 中 通过 .spec.template 设 置 
的 。Pod 模 板 的 定义 方法 和 Pod 的 定义 一 致 ， 但 是 有 一 些 需 要 注意 的 内 


PR 


ae 


* 在 Pod 模 板 中 不 需要 指定 Pod 的 名 称 ， 如 果 指 定 了 ， 不 会 报错 但 是 
不 起 作用 。 因 为 通过 Pod 模 板 创 建 Pod 的 时 候 会 设置 Pod 
的 .metadata.generateName ， 然 后 Pod 的 名 称 就 是 .metadata.generateName 
拼接 上 5 位 随机 码 ， 这 样 做 的 目的 是 为 了 通过 Pod 模 板 创 建 出 来 的 Pod 的 
名 称 是 唯一 的 。 


。Pod 模 板 中 的 重启 策略 必须 是 Always， 因 为 Replication Controller 
要 你 证 Pod 持 续 运 行 ， 必 须要 求 Pod 总 是 重启 容器 ， 不 人 然 谈 何 持续 
行 。 


* Pod E fx F HY Label BEHE, API Replication Controller 无 法 同 
Pod 模 板 创建 出 来 的 Pod 进 行 关联 。 


下 面 是 一 个 Pod 模 板 示例 : 


template: 


metadata: 


labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 


- containerPort: 80 


Replication Controller 使 用 Pod 模 板 创 建 Pod， 一 旦 创建 成 功 ，Pod 模 
板 和 创建 的 Pod 束 没有 关系 了 。 可 以 修改 Pod 模 板 但 不 会 对 已 创建 的 Pod 
有 任何 影响 ， 也 可 以 直接 更 新 通过 Replication Controller 创 建 的 Pod 。 


containers: 


- image: nginx 


name: nginx 
ports: 


- containerPort: 80 


通过 定义 文件 创建 PodTemplate: 


$ kubectl create -f podtemplate.yaml 


podtemplate "nginx" created 


$ kubectl get podTemplate nginx 
TEMPLATE CONTAINER(S) IMAGE(S) PODLABELS 


nginx nginx nginx name=nginx 


另外 ， 在 Replication Controller 定 义 中 可 通过 .spec.templateRef 引 用 
PodTemplate 〈 这 部 分 暂 未 实现 ) 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: my-nginx 
spec: 
replicas: 2 
templateRef: 


name: nginx 


5.3 Replication Controller 和 Pod 的 天 
联 


Replication Controller #1 Pod AY X EX S/b eH Label SS FAY, Label WL 
制 是 Kubernetes 中 很 重要 的 一 个 设计 ， 通 过 Label 进 行 对 象 的 弱 关 联 ， 可 
以 灵活 地 进行 分 类 和 选择 。 残 像 在 社区 网 络 上 ， 对 每 个 人 打上 不 同 的 
标签 : 职业 、 年 龄 、 兴 趣 爱 好 等 ， 然 后 系统 可 以 根据 标签 推送 不 同 的 
业务 ， 以 提供 灵活 的 定制 服务 。 


对 于 Pod， 需 要 设置 Label 来 进行 标识 ，Label 是 一 系列 的 Key/Value 
Xt, Pod (或 者 Pod 模 板 ) 的 定义 中 通过 .metadata.labels 设 置 : 


labels: 
key1: valuet 
key2: value2 


Label 的 定义 是 任意 的 ， 但 是 Label 必 须 具有 可 标识 性 ， 比 如 设置 
Pod 的 应 用 名 称 和 版 本 号 等 。 另 外 ，Label 是 不 具有 唯一 性 的 ， 为 了 更 准 
确 地 标识 Pod， 建 议 为 Pod 设 置 不 同 维度 的 Label， 比 如 : 


wo" "T "T 


* "release" : "stable", "release" : "canary" 


"T "T 


qa", "environment" 


wo 


* "environment" : "dev","environment" 


"production" 


"T "T 


* "tier" : "frontend"," tier" : "backend", "tier" : "cache" 


"T "T u "T 


e "partition" : "customerA","partition" : "customerB" 


e "track" : "daily"," track" : "weekly" 


Xf T Replication Controller ¥# i/i Wi HW Label Selector 来 匹配 Pod 的 
Label, ， 从 而 实现 关联 关系 。 在 Replication Controller HY) 7 Y. FH 38 
过 .spec.selector 来 设置 Label Selector，Replication Controller 的 定义 文件 


my-web-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-web 
spec: 
selector: 
app: my-web 
template: 
metadata: 
labels: 
app: my-web 
version: vi 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 


- containerPort: 80 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-web-rc.yaml 


replicationcontroller "my-web" created 


$ kubectl get replicationcontroller my-web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -web my -web my -web:vi app=my -web 1 
3s 


通过 Label 查 询 Replication Controller 创 建 出 来 的 Pod: 


$ kubectl get pod --selector app=my-web --label-columns-app 
NAME READY STATUS RESTARTS AGE APP 


my -web-itaxw 1/1 Running 0 27S my-web 


可 将 该 Pod 的 Label app=my-web 修 改 挥 : 


$ kubectl label pod my-web-itaxw app=debug --overwrite 


pod "my-web-itaxw" labeled 


通过 查询 可 以 看 到 马上 有 新 的 Pod 被 创建 出 来 ， 因 为 Replication 
Controller 正 是 通过 Label 关 联 Pod，Pod 的 Label 被 修改 掉 ， 对 Replication 
Controller 而 言 相当 于 减少 一 个 关联 的 Pod， 自 然 就 会 创建 新 的 Pod 。 


$ kubectl get pod --selector app --label-columns=app 
NAME READY STATUS RESTARTS AGE APP 
my -web-itaxw 1/1 Running 0 1m debug 


my-web-p411n 171 Running 0 16s my-web 


对 于 修改 标签 的 Pod 来 说 ， 相 当 于 脱离 Replication Controller Hy 7 
制 ， 这 种 方法 适合 对 应 用 进行 调试 〈 或 者 数据 备份 ) ， 相 当 于 有 一 个 
脱离 控制 的 Pod 可 以 进行 调试 ， 最 后 可 以 删除 这 个 Pod: 


$ kubectl delete pod my-web-itaxw 


pod "my-web-itaxw" deleted 


$ kubectl get pod --selector app --label-columns-app 
NAME READY STATUS RESTARTS AGE APP 


my-web-p411n 1/1 Running 0 1m my-web 


如 果 试 图 创建 Label 为 app=my-web 的 Pod， 会 发 现 Pod 是 创建 不 出 来 
的 ， 因 为 这 个 Pod 和 Replication Controller 的 Label Selector tAE f , ABA 
Replication Controller 会 删除 这 个 Pod 来 保证 Pod 的 副本 数 不 多 也 不 少 。 
所 以 当 多 个 Replication Controller 的 Label Selector 一 样 且 设置 的 Pod 副 本 
不 一 样 的 时 候 ， 会 产生 冲突 。 


5.4 弹性 伸缩 


弹性 伸缩 是 指 适应 负载 变化 ， 以 弹性 可 伸缩 方式 提供 资源 ， 特 别 
征 在 虚拟 化 文 持 下 ， 提 高 资源 的 利用 率 和 用 户 满意 度 ， 较 好 地 解决 了 
资源 利用 率 和 应 用 系统 之 间 的 巴 看 ， 古 云 计算 领域 的 关键 能 力 。 想 象 
一 下 现实 世界 ， 比 如 大 型 超市 的 出 口 ， 高 峰 时 期 人 流量 大 的 时 候 ， 适 
时 增加 结算 柜台 ， 而 当 人 流量 少 的 时 候 减 少 结算 柜台 。 


同样 反映 到 Kubernetes 中 ， 可 根据 负载 的 高 低 动 态 调整 Pod 的 副本 
数 ， 目 前 Kubernetes 提 供 了 API 接 口 实现 Pod 的 弹性 伸缩 。 当 然 ，Pod 的 


副本 数 本 来 就 是 通过 Replication Controller 进 行 探 制 ， 所 以 Pod 的 弹性 伸 
HAm æM Replication Controller 的 Pod 副 本 数 ， 可 以 通过 kubectl scale 命 


首先 创建 Replication Controller， 设 置 的 Pod 副 本 数 为 1，Replication 
Controller 的 定义 文件 my-nginx-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-nginx 
spec: 
replicas: 1 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 


restartPolicy: Never 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


Replication Controller 创 建成 功 后 ， 创 建 出 指定 数目 的 Pod: 


$ kubectl get replicationcontroller my-nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -nginx nginx nginx app=nginx 1 
1m 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-sb6my 1/1 Running 0 im 


扩容 Pod 的 副本 数目 到 3: 


$ kubectl scale replicationcontroller my-nginx --replicas=3 


replicationcontroller "my-nginx" scaled 


$ kubectl get replicationcontroller --selector app=nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -nginx nginx nginx app=nginx 3 
2m 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my-nginx-2hzis 1/1 Running 0 49s 
my -nginx-7b66n 1/1 Running 0 49s 


my -nginx-sb6my 1/1 Running 0 2m 


缩 容 Pod 的 副本 数 到 1: 


$ kubectl scale replicationcontroller my-nginx --replicas=1 


replicationcontroller "my-nginx" scaled 


$ kubectl get replicationcontroller --selector app=nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -nginx nginx nginx app=nginx 1 
3m 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-7b66n 1/1 Running 0 im 


kubectl scale 如 果 设 置 --current-replicas 参 数 ， 会 先 检查 当前 的 Pod 的 
副本 数 是 否 匹配 ， 不 匹配 的 话 会 报错 : 


$ kubectl scale rc my-nginx --current-replicas=2 --replicas=1 


Expected replicas to be 2, was 1 


另外 ， 也 可 以 把 Pod 的 副本 数目 设置 为 0， 即 删 BR Replication 
Controller 关 联 的 所 有 Pod: 


$ kubectl scale replicationcontroller my-nginx --replicas=0 


replicationcontroller "my-nginx" scaled 


$ kubectl get replicationcontroller --selector app=nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
my -nginx nginx nginx app=nginx 0 
4m 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


55 自动 伸缩 


通过 Replication Controller 可 以 非常 方便 地 实现 Pod 的 弹性 伸缩 ， 在 
此 基础 上 ， 只 要 有 平台 监控 文 择 ， 就 可 以 实现 目 动 伸 缩 的 功能 ， 即 基 
于 Pod 的 资源 使 用 情况 ， 根 据 配 置 的 策略 目 动 调整 Pod 的 虽 AB 。 


££ Kubernetes + 38i 11 Horizontal Pod Autoscaler 来 实现 Pod 的 自动 伸 
44, Horizontal Pod Autoscaler|z] Replication Controller 是 一 一 对 应 的 ， 


Horizontal Pod Autoscaler 将 定时 从 平台 监控 系统 中 获取 Replication 
Controller 天 联 Pod 的 整体 资源 使 用 情况 。 当 策略 匹配 的 时 候 ， 通 过 
Replication Controller 来 调整 Pod 的 副本 数 ， 实 现 目 动 伸缩 。 


提示 


在 当前 版 本 (Kubernetes v1.1.1) |, Horizontal Pod Autoscaler 
处 于 Beta 测 斌 阶段， 目前 策略 只 支持 根据 CPU 的 使 用 情况 进行 关联， 
并 且 Kubernetes 需 要 安装 平台 监控 (可 参考 2.3.2 节 ) ° 


通过 kubectl run 创 建 Replication Controller， 将 运行 一 个 Nginx Pod: 


$ kubectl run nginx --image=nginx --labels app=nginx --requests 
cpu=200m 


replicationcontroller "nginx" created 


$ kubectl get replicationcontroller nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
nginx nginx nginx app=nginx 1 
im 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


nginx-dqsvi 1/1 Running 0 1m 


通过 kubectl exposef!| Service, fV X8 Nginx Pod， 然 后 就 可 以 通过 
http://10.254.133.192 访 问 Nginx Pod: 


$ kubectl expose replicationcontroller nginx --port=80 


service "nginx" exposed 


$ kubectl get service nginx 


NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR 
AGE 
nginx 110.254.133.192 <none> 80/TCP app=nginx 


5s 


现在 将 创建 Horizontal Pod Autoscaler 来 实现 Nginx Pod 的 弹性 伸 
44, Horizontal Pod Autoscaler 定 义 文件 nginx-hpa.yaml: 


apiVersion: extensions/vibeta1 
kind: HorizontalPodAutoscaler 
metadata: 
name: nginx 
namespace: default 
spec: 
scaleRef: 
kind: ReplicationController 
name: nginx 
subresource: scale 
minReplicas: 1 
maxReplicas: 10 
cpuUtilization: 


targetPercentage: 50 


1£ Jf, Horizontal Pod Autoscaler 中 通过 .spec.scaleRef 指定 对 应 的 
ReplicationController ， .spec.minReplicas 和 .spec.maxReplicas 分 别 设 定 
Pod 伸 缩 的 最 小 和 最 大 副本 数 。 为 外 设置 了 目 动 伸缩 策略 : 当 所 有 关联 
Pod i CPU 平均 使 用 率 超过 50% 的 时 候 进 行 扩容 ， 而 少 于 50% 的 时 
候 ， 进 行 缩 容 。 


现在 通过 定义 文件 创建 Horizontal Pod Autoscaler: 


$ kubectl create -f nginx-hpa.yaml 


horizontalpodautoscaler "nginx" created 


提示 


可 以 通过 kubectl autoscale 创 建 Horizontal Pod Autoscaler: 


$ kubectl autoscale rc nginx --min=1 --max-10 --cpu-percent=50 


replicationcontroller "nginx" autoscaled 


创建 成 功 后 查询 Horizontal Pod Autoscaler: 


$ kubectl get horizontalpodautoscaler nginx 

NAME REFERENCE TARGET 
CURRENT MINPODS MAXPODS AGE 

nginx ReplicationController/nginx/scale 50% 0% 1 


10 id 


因为 没有 访问 量 ， 所 以 当前 关联 pod 的 CPU 平 使 用 率 为 0%， 我 们 可 
以 使 用 工具 增加 访问 量 。 当 访问 量 增加 的 上 时候， 查询 Horizontal Pod 


Autoscaler， 观 察 变 化 : 


$ kubectl get horizontalpodautoscaler nginx 
NAME REFERENCE TARGET 
CURRENT MINPODS MAXPODS AGE 


nginx ReplicationController/nginx/scale 50% 60% 1 


10 id 


当 CPU 平 均 使 用 紊 超过 50% 的 时 候 ， 可 以 发 现 对 应 的 Replication 
Controller 的 Pod 副 本 数 变 为 2， 实 现 了 扩容 。 


$ kubectl get horizontalpodautoscaler nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
nginx nginx nginx app=nginx 2 
10m 


当 我 们 停止 访问 ，CPU 平 均 使 用 率 降 到 50% 以 下 ，Replication 
Controller 的 Pod 副 本 数 变 为 1， 即 实现 了 缩 容 。 


$ kubectl get horizontalpodautoscaler nginx 

NAME REFERENCE TARGET 
CURRENT MINPODS  MAXPODS AGE 

nginx ReplicationController/nginx/scale 50% | 4396 1 
10 1d 


$ kubectl get replicationcontroller nginx 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS 
AGE 
nginx nginx nginx app=nginx 1 
12m 


5.6 ”滚动 升级 


RRA AGE PP EAI BA TN, TR AR, A 
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以 保证 问题 影响 度 不 会 扩大 。 


在 Kubernetes 中 文 持 滚 动 升 级 ， 现 在 我 们 通过 一 个 例子 演示 应 用 从 
V1 版 本 深 动 升级 到 V2 版 本 。 首 先 创建 V1 版 本 的 Replication Controller, 
V1 版 本 的 Replication Controller 的 定义 文件 my-web-v1-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-web-v1i 
spec: 
selector: 
app: my-web 
version: vi 
template: 
metadata: 
labels: 
app: my-web 
version: vi 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 
- containerPort: 80 


protocol: TCP 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-web-vi-rc.yaml 


replicationcontroller "my-web-vi" created 


$ kubectl get replicationcontroller my-web-v1 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 

my -web-vi my -web my-web:vi app-my-web, version-vi 


1 10s 


然后 扩容 Replication Controller 的 Pod 副 本 数目 到 4: 


$ kubectl scale rc my-web-v1 --replicas=4 


replicationcontroller "my-web-vi" scaled 


$ kubectl get pods --selector app=my-web 


NAME READY STATUS RESTARTS AGE 
my -web-vi-3dd6v 1/1 Running 0 9s 
my -web-v1-8893c 1/1 Running 0 57S 
my-web-vi-il6ii 1/1 Running 0 8s 
my-web-vi-rzjp5 1/1 Running 0 9s 


现在 需要 应 用 从 V1 版 本 升级 到 v2 版 本 ，V2 版 本 的 Replication 
Controller 定义 文件 my-web-v2-rc.yaml: 


apiVersion: vi 
kind: ReplicationController 


metadata: 


name: my-web-v2 
spec: 
selector: 
app: my-web 
version: v2 
template: 
metadata: 

labels: 
app: my-web 
version: v2 

spec: 

containers: 

- name: my-web 
image: my-web:v2 
ports: 

- containerPort: 80 


protocol: TCP 


开始 滚动 升级 : 


$ kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml -- 
update-period=10s 

Created my-web-v2 

Scaling up my-web-v2 from 0 to 4, scaling down my-web-vi from 4 
to 0 (keep 4 pods available, 

don't exceed 5 pods) 

Scaling my-web-v2 up to 1 


Scaling my-web-vi down to 3 


Scaling my-web-v2 up to 2 

Scaling my-web-vi down to 2 

Scaling my-web-v2 up to 3 

Scaling my-web-vi down to 1 

Scaling my-web-v2 up to 4 

Scaling my-web-vi down to 0 

Update succeeded. Deleting my-web-v1i 


replicationcontroller "my-web-vi" rolling updated to "my-web-v2" 


升级 开始 后 ， 首 先 根据 提供 的 定义 文件 创建 V2 版 本 的 Replication 
Controller ， 然 后 每 隔 10s (通过 kubectl rolling-update 的 参数 --update- 
period 设 置 ) 逐步 增加 V2 版 本 的 Replication Controller 的 Pod 副 本 数 ， 球 
步 减 少 V1 版 本 的 Replication Controller 的 Pod 副 本 数 。 升 级 完成 后 删除 
V1 版 本 的 Replication Controller， 保 留 V2 版 本 的 Replication Controller, 
即 实现 滚动 升级 。 


Updating my-web-vi replicas: my-web-v2 replicas: 


Updating my-web-vi replicas: my-web-v2 replicas: 


Updating my-web-vi replicas: my-web-v2 replicas: 


pr quos N 
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Updating my-web-vi replicas: my-web-v2 replicas: 


升级 期 间 通过 查询 Pod 可 知 ，V2 版 本 的 Pod 正 在 逐渐 蔡 换 V1 版 本 的 
Pod， 当 然 这 是 通过 调整 Replication Controller 的 副本 数目 来 控制 的 ， 下 
面 显示 的 是 升级 过 程 中 的 一 个 阶段 的 状况 : 


$ kubectl get replicationcontroller --selector app=my-web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 


my -web-v1i my -web my-web: vi app=my-web, version-vi 


2 2m 
my-web-v2 my -web my-web:v2 app=my-web, version=v2 
2 48s 


$ kubectl get pod --selector app=my-web 


NAME READY STATUS RESTARTS AGE 
my -web-vi-3dd6v 1/1 Running 0 1m 
my -web-v1-8893c 1/1 Running 0 2m 
my -web-v2-6cg74 1/1 Running 0 19s 
my -web-v2-b4qaz 1/1 Running 0 45S 


每 升级 完成 ， 即 V2 版 本 的 Pod 完 全 替换 V1 版 本 的 Pod， 同 时 V1 版 本 
的 Replication Controller 也 被 V2 版 本 的 Replication Controller A: 


$ kubectl get replicationcontroller --selector app=my-web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS 
my-web-v2 my -web my -web:v2 app=my -web , 


version=v2 4 


$ kubectl get pod --selector app=my -web 


NAME READY STATUS RESTARTS AGE 

my -web-v2-7850k 1/1 Running 0 35s 
my -web-v2-bg8ur 1/1 Running 0 im 
my -web-v2-qr33c 1/1 Running 0 im 
my -web-v2-y2es3 1/1 Running 0 57S 


如 采 在 升级 过 程 中 ， 发 生 了 错误 中 还 退 出 的 时 候 ， 可 以 选择 继续 
升级 。Kubemetes 能 够 佑 能 地 判断 出 升级 中 断 之 前 的 阶段 ， 然 后 紧 接 奢 
继续 执行 升级 。 男 外 ， 也 可 以 进行 回 退 ， 命 令 如 下 : 


$ kubectl rolling-update my-web-v1 -f my-web-v2-rc.yaml -- 
update-period-10s --rollback 

Setting "my-web-vi" replicas to 4 

Continuing update with existing controller my-web-v1. 

Scaling up my-web-vi from 3 to 4, scaling down my-web-v2 from 2 
to 0 (keep 2 pods available, 

don't exceed 3 pods) 

Scaling my-web-v2 down to 0 

Scaling my-web-vi up to 4 


Update succeeded. Deleting my-web-v2 


[E BJ 7; SUSE EEA RAN BRE, BP ÉD VIA 
Replication Controller HY) &| Æ Z& , XX A Ui ^b V2 fig AS BY Replication 
Controller 的 副本 数 。 


5.7 Deployment 


Kubernetes 提 供 了 一 种 更 加 简单 的 更 新 Replication Controller 和 Pod 
的 机 制 ， 叫 作 Deployment ° 


提示 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Deployment 处 于 beta 测 试 
阶段 ， 需 要 Kubernetes API Server 的 启动 参数 设置 --runtime- 
config=extensions/vlbetal/deployments=true 开 局 Deployment 文 持 。 


我 们 创建 一 个 Deployment，Deployment 的 定义 文件 my-web-v1- 
deployment.yaml: 


apiVersion: extensions/vibetai 
kind: Deployment 
metadata: 
name: my-web-deployment 
spec: 
replicas: 4 
template: 
metadata: 
labels: 
app: my-web 
spec: 
containers: 
- name: my-web 
image: my-web:v1 
ports: 
- containerPort: 80 


protocol: TCP 


Deploymentf' Y. 77 1& 5j Replication Controller 类 似 ， 包 括 Pod 副 本 
数 和 Pod 副 本 的 设置 ， 这 些 定 义 将 会 作用 于 Deployment 创 建 的 


Replication Controller ° 
通过 定义 文件 创建 Deployment: 


$ kubectl create -f my-web-v1-deployment.yaml --validate-false 


deployment "my-web-deployment" created 


ll] € py, 7j Jk; n] DÀ # 38] $1 Deployment 和 其 创建 的 Replication 


Controller: 


$ kubectl get deployment my-web-deployment 
NAME UPDATEDREPLICAS AGE 


my-web-deployment 0/4 32s 


$ kubectl get replicationcontroller --selector app=my -web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 

deploymentrc-3379117081  my-web my-web:v1 app=my -web , 


deployment .kubernetes.io/podTemplateHash=3379117081 0 21s 


Deployment 创 建 出 来 的 Replication Controller] 44 fj 4 deploymentrc- 
3379117081, Replication Controller 使 用 的 是 Deployment 定 义 中 的 Pod 模 
板 。 


Deployment 给 Replication Controller 添加 了 一 个 Label 
deployment.kubernetes.io/ podTemplateHash-3379117081, ， 其 中 Label 的 
Value 是 3379117081， 这 是 由 Pod 模 板 计算 出 的 Hash 值 ，Label 的 Key 是 由 
Deployment 中 的 .specuniqueLabelKey 指定 的 ， 默 U Æ 


deployment.kubernetes.io/podTemplateHash, WU AZ, WARSI 
Label ° 


Deployment 中 通过 .spec.replicas 指 定 了 预期 的 Pod 副 本 数 ， 不 过 在 刚 
创建 的 时 候 ， 初 始 值 是 0。 


过 一 段 时 间 后 ，Deployment 将 会 设置 Replication Controller 的 Pod 副 | 
本 数 为 4， 相 应 地 创建 出 了 4 个 Pod: 


$ kubectl get deployment my-web-deployment 
NAME UPDATEDREPLICAS AGE 


my-web-deployment 4/4 50s 


$ kubectl get replicationcontroller --selector app=my-web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 


deploymentrc-3379117081 my -web my-web:vi app=my -web , 
deployment .kubernetes.io0/podTemplateHash=3379117081 4 im 
$ kubectl get pods  --selector  appzmy-web  --label-columns 


deployment.kubernetes.io/ 


podTemplateHash 

NAME READY STATUS 
RESTARTS AGE PODTEMPLATEHASH 
deploymentrc-3379117081-5ghmj 1/1 Running 0 
1m 3379117081 

deploymentrc-3379117081-g4a0i 1/1 Running 0 


im 3379117081 


deploymentrc-3379117081-orckb 1/1 Running 9 


im 3379117081 
deploymentrc-3379117081-r69kt 1/1 Running 0 
1m 3379117081 


现在 我 们 需要 更 新 应 用 ， 镜 像 my-web:v1 升 级 到 my-web:v2 ， 为 
此 ， 新 的 Deployment 定 义 文件 my-web-v2-deployment.yaml 如 下 所 示 : 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: my-web-deployment 
spec: 
replicas: 4 
template: 
metadata: 
labels: 
app: my-web 
spec: 
containers: 
- name: my-web 
image: my-web:v2 
ports: 
- containerPort: 80 


protocol: TCP 


使 用 新 的 定义 文件 更 新 Deployment: 


$ kubectl apply -f my-web-v2-deployment.yaml --validate=false 


deployment "my-web-deployment" configured 


更 新 生效 后 ， 可 以 查询 到 Deployment 创 建 了 新 的 Replication 


Controller: 


$ kubectl get replicationcontroller --selector app=my-web 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 

deploymentrc-3379117081 my -web my-web:vi app=my-web , 

deployment .kubernetes.io/podTemplateHash=3379117081 4 2m 
deploymentrc-3445177370 my -web my -web: v2 app=my-web , 

deployment .kubernetes.io/podTemplateHash=3445177370 © 6s 


新 创建 出 的 Replication Controller T5 7jdeploymentrc-3445177370, 
Label ix & 7j deployment.kubernetes.io/podTemplateHash-3445177370 , 
3445177370 z= F1 39r AY Pod ES Hx it $ H1 AY Hash (E, tf 8 Replication 
Controller 使 用 镜像 my-web:v2， 初 始 的 Pod 副 本 数 为 0 。 


AE Deployment, e f 8/391: IH Replication Controller ， 实 现 Pod 的 
升级 : 


$ kubectl get replicationcontroller --selector app=my-web 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS AGE 


deploymentrc-3379117081  my-web my -web:vi app-my-web, 
deployment.kubernetes.io/podTemplateHash-3379117081 0 Am 
deploymentrc-3445177370 my-web my -web: v2 app=my-web, 


deployment .kubernetes.io/podTemplat eHash=344517 7370 4 2m 


$ kubectl get pod  --selector  appzmy-web --label-columns 


deployment .kubernetes.io/ 


podTemplateHash 

NAME READY STATUS 
RESTARTS AGE PODTEMPLATEHASH 
deploymentrc-3445177370-4ej3a 1/1 Running 0 
2m 3445177370 

deploymentrc-3445177370-1327a T/1 Running 0 
1m 3445177370 

deploymentrc-3445177370-reeqh 1/1 Running 0 
46s 3445177370 

deploymentrc -3445177370-zhopb 1/1 Running 0 
1m 3445177370 


默认 情况 下 ，Deployment 和 采取 的 是 滚动 升级 方式 ， 同 使 用 kubect 
rolling-update 是 一 致 的 ， 即 逐步 增加 新 的 Replication Controller 的 副本 
数 ， 了 逐步 减少 旧 的 Replication Controller 的 副本 数 ， 通 过 查询 
Deployment 的 事件 可 以 看 到 具体 变化 情况 : 


$ kubectl describe deployment my-web-deployment 


Scaled up rc deploymentrc-3379117081 to 4 
Scaled up rc deploymentrc-3445177370 to 1 
Scaled down rc deploymentrc-3379117081 to 2 
Scaled up rc deploymentrc-3445177370 to 3 
Scaled down rc deploymentrc-3379117081 to 0 


Scaled up rc deploymentrc-3445177370 to 4 


在 Deployment 中 可 以 配置 升级 的 策略 ， 通 过 .spec.strategytype 指 定 
升级 类 型 ， 包 括 Recreate 和 RollingUpdate ° 


。Recreate: 直接 升级 ， 即 删除 所 有 旧 的 Pod， 然 后 创建 新 的 Pod， 
当前 版 本 (Kubernetes v1.1.1) 暂 未 实现 。 


* RollingUpdate: 滚动 升级 ， 文 持 参 数 配 置 ， 如 表 5-1 所 示 。 


表 5-1 RollingUpdate 策 略 参 数 


参数 说 明 


允许 的 最 大 失效 Pod 数 
值 ， 可 选 配 置 ， 值 可 以 
是 绝对 值 (5) 或 者 是 
比例 (10%) ， 默 认 值 
是 1。 比 如 
maxUnavailable 是 30%， 
升级 开始 后 ， 旧 的 
.spec.strategy.rollingUpdate.maxUnavailable | Replication Controller 4] 
以 立即 缩 容 30% 的 Pod， 
当 新 的 Replication 
Controller 创 建 出 Pod 以 
后 ， 旧 的 Replication 
Controller 可 以 进一步 缩 
容 ， 整 个 升级 过 程 至 少 
需要 保证 70% 的 Pod 可 用 


.spec.strategy.rollingUpdate.maxSurge 允许 超过 指定 Pod 数 目 


的 最 大 数值 ， 可 选 配 
置 ， 值 可 以 是 绝对 值 
(5) 或 者 是 比例 
(10%) ， 默 认 值 是 1。 
比如 maxSurge 是 309%6， 
升级 开始 后 ， 新 的 
Replication Controller 可 
以 立即 扩容 30%， 旧 的 
Replication Controller 删 
除 Pod 之 后 ， 新 的 
Replication Controller 可 
以 继续 扩容 ， 在 整个 过 
程 中 ， 新 旧 Pod 的 总 数 
目 不 可 以 超过 指定 数目 
的 130% 


5.8 一 次 性 任务 的 Pod 


从 程序 运行 形态 上 来 区 分 ， 我 们 可 以 将 Pod 分 为 两 类 ， 长 时 运行 服 
务 和 一 次 性 任务 。 大 部 分 应 用 比如 Nginx、Redis 等 都 是 长 时 运行 服务 ， 
另外 也 存在 一 次 性 任务 的 场景 ， 比 如 执行 冒 烟 测试 、 数 据 计 算 等 。 


Replication Controller 创 建 的 Pod 都 是 长 时 运行 服务 ， 相 应 的 ， 
Kubernetes 提 供 了 另 一 种 机 制 ，Job 来 管理 一 次 性 任务 的 Pod 。 


提示 : 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Job 处 于 Beta 测 试 阶段 。 


我 们 现在 使 用 Job 来 计算 圆周 率 ，Job 的 定义 文件 pi-job.yaml; 


apiVersion: extensions/vibeta1 
kind: Job 
metadata: 
name: pi 
spec: 
completions: 1 
parallelism: 1 
selector: 
matchLabels: 
app: pi 
template: 
metadata: 
name: pi 
labels: 
app: pi 
spec: 
containers: 
- name: pi 
image: perl 


command: ["perl", "-Mbignum-bpi",  "-wle", "print 


bpi(2000)"] 


restartPolicy: Never 


Job 同 样 是 通过 .spec.template 配 置 Pod 的 模板 的 ， 因 为 是 一 次 性 任务 
Pod， 所 以 Pod 的 重启 策略 只 能 是 Never 或 者 OnFailure ° 


Job 可 以 控制 一 次 性 任务 Pod 的 完成 次 数 (.spec.completions) 和 并 
发 执行 数 (spec. parallelism) ， 当 Pod 成 功 执行 指定 次 数 后 即 认 为 Job 
执行 完毕 。 

通过 定义 文件 创建 Job: 
$ kubectl create -f pi-job.yaml 


job "pi" created 


$ kubectl get job 
JOB CONTAINER(S) IMAGE(S) SELECTOR SUCCESSFUL 


pi pi perl app in (pi) 9 


Job 创 建成 功 后 ， 将 会 创建 运行 Pod: 


$ kubectl get pod --selector app=pi 
NAME READY STATUS RESTARTS AGE 
pi-8117p 1/1 Running 0 6s 


Pod 是 一 次 性 任务 ， 计 算出 圆周 率 就 终止 ， 我 们 可 以 查询 到 Pod 输 
出 的 圆周 率 : 


$ kubectl logs pi-8117p 
3.14159265358979323846264338327950288419716939937510582097494459 


2307816406286208998628034... 


在 一 次 性 任务 Pod 执 行 完 后 ， 显 示 Job 已 经 成 功 执行 1 次 ， 即 完成 任 
务 : 


$ kubectl get job pi 
JOB CONTAINER(S) IMAGE(S) SELECTOR SUCCESSFUL 


pi pi perl app in (pi) 1 


第 6 章 


Service 


为 了 适应 快速 的 业务 需求 ， 微 服务 以 构 已 经 逐渐 成 为 主流 ， 微 服 
务 架 构 的 应 用 需要 有 非常 好 的 服务 编排 文 持 。Kubernetes 中 的 核心 要 
素 Service 便 提供 了 一 套 简 化 的 服务 代理 和 发 现 机 制 ， 天 然 适 应 微服 务 
染 构 ， 任 何 应 用 都 可 以 非常 轻易 地 运行 在 Kubernetes 中 而 无 须 对 架构 
进行 改动 。 本章 将 阐述 Service 的 基本 概念 和 功能 细节 ， 最 后 介绍 如 何 
将 Service 发 布 给 外 部 网 络 的 方法 。 


6.1 ”Service 代 理 Pod 


在 Kubernetes 中 ， 在 受到 Replication Controller 支 配 的 时 候 ，Pod 副 
本 是 变化 的 ， 比 如 发 生 迁 移 (准确 说 是 Pod 的 重建 ) 或 者 伸缩 的 时 
修 。 这 对 于 Pod 的 访问 者 来 说 束 是 一 种 人 负担， 访问 者 需要 能 够 发 现 这 
些 Pod 副 本 ， 并 且 感 知 Pod 副 本 的 变化 以 便 及 时 进行 更 狐 。 


Kubermnetes 中 的 Service 是 一 种 抽象 概念 ， 它 定义 了 一 个 Pod 逻 辑 集 
合 以 及 访问 它们 的 策略 ，Service 同 Pod 的 关联 同样 是 大 于 Label 来 完成 
的 。Service 的 目标 是 提供 一 种 桥梁 ， 它 会 为 访问 者 提供 一 个 固定 访问 
地 址 ， 用 于 在 访问 时 重 定 向 到 相应 的 后 端 ， 这 使 得 非 Kubernetes 原 生 
应 用 程序 ， 在 无 须 为 Kubermnetes 编 写 特定 代码 的 前 提 下 ， 轻 松 访问 后 


端 。 


我 们 现在 定义 一 个 Service 来 代理 Pod， 首 先 创 建 Replication 
Controller, Replication Controller 的 定义 文件 my-nginx-rc.yaml: 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: my-nginx 
spec: 
replicas: 3 
selector: 
app: nginx 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 


- containerPort: 80 


通过 定义 文件 创建 Replication Controller: 


$ kubectl create -f my-nginx-rc.yaml 


replicationcontroller "my-nginx" created 


Replication Controller!) H13 1 Pod&il| A: 


$ kubectl get pod --selector app=nginx 


NAME READY STATUS RESTARTS AGE 

my -nginx-2ywz1 1/1 Running 0 im 
my -nginx-arjqi 1/1 Running 0 im 
my -nginx-tokOx 1/1 Running 0 im 


然后 创建 Service，Service 的 定义 文件 my-nginx-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: my-nginx 
spec: 
selector: 
app: nginx 
ports: 
- port: 80 
targetPort: 80 


protocol: TCP 


XE SUC FP flt T Service] ES EMTAK, RPBJSESESESRAU BAT 
ZN 


e apiVersion: 声明 Kubernetes 的 API 版 本 ， 目 前 是 v1。 
。kind: 声明 API 对 象 的 类 型 ， 这 里 类 型 是 Service 。 


* metadata: 设置 Service 的 元 数据 。 


name: 指定 Service 的 名 称 ， 名 称 必须 在 Namespace 内 唯一 。 
。spec: 配置 Service 的 具体 规格 。 


e selector: 指定 Service 的 Label Selector% [i Pod ^J Label ° 
‘ports: 设置 Service 的 端口 转发 规则 o 


通过 定义 文件 创建 Service: 


$ kubectl create -f my-nginx-service.yaml 


service "my-nginx" created 


除了 kubectl create Z 9h, t, PJ DA iÑ xf kubectl expose 创建 


Service: 


$ kubectl expose replicationcontroller my-nginx --name=my- 


nginx --port=80 --target- 
port=80 


service "my-nginx" exposed 


创建 成 功 后 可 以 查询 Service: 


$ kubectl get service my-nginx 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR 
AGE 


my -nginx 100.254.226.117 <none> 80/TCP app=nginx 
43s 


Service |=] Replication Controller 一 样 都 是 通过 Label 来 关联 Pod 的 ， 
Service 的 定义 中 指定 了 Label Selector 为 app= nginx, BA 束 会 天 联 前 面 
运 a 的 3 个 Pod。Service 会 将 关联 到 的 Pod 作 为 Service 分 发 请 求 的 后 

， 可 以 查询 Service: 


$ kubectl describe service my-nginx 

Name: my -nginx 

Namespace: default 

Labels: <none> 

Selector: app=nginx 

Type: ClusterIP 

IP: 10.254.226.117 

Port: «unnamed» 80/TCP 

Endpoints:  10.0.62.68:80, 10.0.62.69:80, 10.0.62.70:80 
Session Affinity: None 


No events. 


可 以 看 到 Service 的 Endpoints 属 性 包含 了 3 个 卫 : 10.0.62.68 ` 
10.0.62.69、10.0.62.70， 实 际 上 这 惑 是 Service 天 联 的 3 个 Pod 的 PodIP: 


$ kubectl get pod --selector app=nginx -0 yaml|grep podIP 
podIP: 10.0.62.70 
podIP: 10.0.62.68 
podIP: 10.0.62.69 


我 们 看 到 ，Service 的 IP 属 性 显示 为 10.254.226.117， 实 际 上 这 是 
Kubermnetes 分 配给 Service 的 一 个 虚拟 IP。 通 过 访问 Service 的 虚拟 IP， 
Kubernetes 会 转发 请 求 到 后 端 Pod。 另 外 ，Service 的 端口 转发 规则 显示 
Service 的 80/TCP 端 口 (通过 spec.ports[0].port 指 定 ) 转发 到 后 端的 80 端 
O (通过 spec.ports[0].targetPort 指 定 ) ， 比 如 访问 10.254.226.117:80 的 
请 求 会 被 转发 到 后 端 10.0.62.68:80、10.0.62.69:80、10.0.62.70:80: 


$ curl 10.254.226.117:80 


...Thank you for using nginx... 


而 当 Pod 发 生变 化 的 时 候 ，Service 会 及 时 更 新 ， 比 如 将 Pod 的 副本 
数目 减少 至 1: 


$ kubectl scale replicationcontroller my-nginx --replicas=1 


replicationcontroller "my-nginx" scaled 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-tokOx 1/1 Running 0 7m 


Service 相 应 地 进行 了 更 新 : 


$ kubectl describe service my-nginx 
Name: my -nginx 

Namespace: default 

Labels: <none> 

Selector: app=nginx 


Type: ClusterIP 


IP: 10.254.226.117 


Port: <unnamed> 80/TCP 


Endpoints: 


10.0.62.69:80 


Session Affinity: None 


No events. 


这 样 一 来 ，Service 就 可 以 作为 Pod 的 访问 入 口 ， 起 到 代理 服务 器 


的 作用 ， 而 对 于 访问 者 来 说 ， 通 过 Service 进 行 访 问 ， 无 须 直 接 感知 


Pod ° 


6.2 ”Service 的 虚拟 IP 


Kubernetes 分 配给 Service 一 个 固定 IP， 这 是 一 个 虚拟 IP (也 称 为 
ClusterIP) ， 并 不 是 一 个 真实 存在 的 耻 ， 而 是 由 Kubernetes 虚 拟 出 来 
的 。 虚 拟 卫 的 范围 通过 Kubernetes API Server 的 启动 参数 --service- 
cluster-ip-range=10.254.0.0/16 配 置 ， 查 询 Service: 


$ kubectl get service 


NAME 
SELECTOR 
kubernetes 
<none> 

my -nginx 


app=nginx 


CLUSTER_IP EXTERNAL_IP PORT(S) 
AGE 
10.254.0.1 «none» 443/TCP 
ed 
10.254.226.117 «none» 80/TCP 
43S 


可 以 查询 到 两 个 Service， 其 中 第 一 个 Service 是 由 Kubernetes 默 认 
创建 的 ， 它 代表 着 Kubernetes API Server。 两 个 Service 的 虚拟 IP 都 属于 


10.254.0.0/16 范 围 ， 在 Service 定 义 中 可 以 通过 .spec.clusterIP 指 定 虚 拟 
IP， 指 定 的 IP 必 须 在 指定 范围 内 ， 并 且 该 虚拟 IP 未 被 分 配 使 用 : 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


clusterIP: 10.254.249.161 


如 果 Service ix &.spec.clusterIP 7j None， 表 示 不 给 Service 分 配 虚 
拟 IP， 我 们 称 为 Headless Service: 


apiVersion: v1 
kind: Service 
metadata: 
name: my-nginx 
spec: 
selector: 
app: nginx 


ports: 


- name: http 
port: 80 
targetPort: 80 
protocol: TCP 


clusterIP: None 


虚拟 IP 属 于 Kubernetes 内 部 的 虚拟 网 络 ， 外 部 是 寻 址 不 到 的 。 在 
Kubernetes 系 统 中 ， 实 际 上 是 由 Kubernetes Proxy 组 件 负 责 实 现 虚 拟 IP 
路 由 和 转发 的 ， 所 以 在 Kubernetes Node 中 我 们 都 运行 了 Kubernetes 
Proxy， 从 而 在 容器 窗 盖 网 络 之 上 叉 实 现 了 Kubernetes 层 级 的 虚拟 转发 
网 络 。 


6.3 ”服务 代理 


在 逻辑 层面 上 ，Service 可 以 被 认为 是 真实 应 用 的 抽象 ， 每 一 
Service 关 联 着 一 系列 的 Pod。 在 物理 层面 上 ，Service 又 是 真实 应 用 的 
代理 服务 器 ， 对 外 表现 为 一 个 单一 访问 入 口 ， 通 过 Kubernetes Proxy 转 
发 请 求 到 Service 关 联 的 Pod ° 


Service 同 样 是 根据 Label Selector tii wt Podi# íT KKH), EIE 
Kubernetes7£ Service #ilPod Z |H]38 1 Endpointsfi}#, Endpoints|] Service 
关联 的 Pod 相 对 应 ， 可 以 认为 是 Service 的 服务 代理 后 端 ，Kubernetes 会 
根据 Service 关 联 到 的 Pod 的 PodIP 信 息 组 合成 一 个 Endpoints。 


我 们 现在 创建 一 个 Service， 定 义 文 件 my-nginx-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 

- name: https 
port: 443 
targetPort: 443 


protocol: TCP 


Service 的 定义 中 设置 了 两 个 端口 转发 规则 。 当 Service 只 配置 一 
个 端口 的 时 候 ， 端 口 的 名 称 是 可 选项 ， 而 当 Service 配 置 多 个 端口 的 时 


候 ， 每 个 端口 的 name 就 是 必 选 项 。 
通过 定义 文件 创建 Service: 


$ kubectl create -f my-nginx-service.yaml 


service "my-nginx" created 


$ kubectl get service my-nginx 


NAME CLUSTER IP EXTERNAL IP 


PORT(S) 


SELECTOR AGE 


my -nginx 10.254.181.218 <none> 80/TCP , 


app=nginx 3s 


Service 将 通过 Label app2nginxX EX 8] 147 Pod: 


$ kubectl get pod --selector app=nginx 
NAME READY STATUS RESTARTS AGE 


my -nginx-4s97i 1/1 Running 0 48s 


443/TCP 
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Endpoints: 


$ kubectl get endpoints my-nginx -o yaml 
apiVersion: vi 
kind: Endpoints 
metadata: 
creationTimestamp: 2015-11-28T03:35:52Z 
name: my-nginx 
namespace: default 


resourceVersion: "224471" 


selfLink: /api/vi/namespaces/default/endpoints/my -nginx 


uid: 1ff974f4-9581-11e5-b92e-005056817c3e 
subsets: 
- addresses: 
- ip: 10.0.62.71 
targetRef: 


kind: Pod 


name: my-nginx-4s97i 
namespace: default 
resourceVersion: "224453" 


uid: 33e8b6e0-9581-11e5-b92e-005056817c3e 


ports: 
- name: http 
port: 80 


protocol: TCP 
- name: https 
port: 443 


protocol: TCP 


可 以 看 到 Endpoints 包 含 Service 关 联 到 的 Pod 的 PodIP , 
端口 对 应 Endpoints 的 相应 端口 : 


$ kubectl describe service my-nginx 
Name: my-nginx 

Namespace: default 

Labels: <none> 

Selector: app=nginx 

Type: ClusterIP 

IP: 10.254.181.218 

Port: http 80/TCP 

Endpoints: 10.0.62.71:80 

Port: https 443/TCP 


Endpoints: 10.0.62.71:443 


Service 根 据 


Session Affinity: None 


No events. 


Service 不 仅 可 以 代理 Pod， 还 可 以 代理 任意 其 他 后 端 ， 比 如 运行 
在 Kubernetes 外 部 的 服务 。 假 设 现在 要 使 用 一 个 Service 代 理 外 部 
MySQL 服 务 ， 不 用 设置 Service 的 Label Selector, ，Service 的 定义 文件 


mysql-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
name: mysql 
spec: 
ports: 
- port: 3036 
targetPort: 3036 


protocol: TCP 


同时 定义 跟 Service 同 名 的 Endpoints，Endpoints 中 设置 了 MySQL 的 
IP: 192.168.3.180，Endpoints 的 定义 文件 mysql-endpoints.yaml: 


apiVersion: v1 
kind: Endpoints 
metadata: 

name: mysql 
subsets: 
- addresses: 


- ip: 192.168.3.180 


ports: 
- port: 3036 


protocol: TCP 


通过 定义 文件 创建 Service 和 Endpoints: 


$ kubectl create -f mysql-service.yaml -f mysql-endpoints.yaml 
service "mysql" created 


endpoints "mysql" created 


可 以 查询 到 Service 将 指 疝 我 们 自 定义 的 Endpoints: 


$ kubectl get endpoints mysql 
NAME ENDPOINTS AGE 
mysql 192.168.3.180:3036 23s 


$ kubectl describe service mysql 
Name: mysql 

Namespace: default 

Labels: «none» 

Selector: <none> 

Type: ClusterIP 

IP: 10.254.223.0 

Port: <unnamed> 3036/TCP 
Endpoints: 192.168.3.180:3036 
Session Affinity: None 


No events. 


当 Service 的 Endpoints 包 含 多 个 IP 的 时 候 ， 即 服务 代理 存在 多 个 后 

端 ， 将 进行 请 求 的 负载 均衡 ， 默 认 的 负载 均衡 策略 是 轮 询 或 者 随机 

(根据 Kubernetes Proxy 的 模式 决定 ) 。Service 文 持 基 于 源 了 地址 的 会 
话 保持 ， 通 过 .spec.sessionAffinity 设 置 为 ClientIP: 


apiVersion: vi 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 
protocol: TCP 


sessionAffinity: ClientIP 


64 ”服务 发 现 


微服 务 架构 是 一 种 新 流行 的 架构 模式 ， 相 比 于 传统 的 单 块 架 构 模 
式 ， 微 服务 架构 提倡 将 应 用 划分 成 一 组 小 的 服务 。 每 个 服务 运行 在 其 
独立 的 进程 中 ， 服 务 之 间 互 相 协 调 、 互 相配 合 ， 服 务 与 服务 间 采 用 轻 
量 级 的 通信 机 制 互相 沟通 。 每 个 服务 都 围绕 着 具体 业务 进行 构建 ， 并 
且 能 够 被 独立 部 署 和 运行 。 


nf LA yi DockerB*) #4 ZG di DIN KATE BR RJ, BE ik 
服务 都 通过 Docker 进 行 打包 、 部 署 和 运行 。 而 Docker 的 集装箱 能 力 为 
微服 务 架 构 保 轰 护 航 ， 可 以 快速 、 轻 松 地 实现 每 个 组 件 的 测试 和 升 
级 ， 将 微服 务 架构 的 优势 最 大 化 。 


但 是 应 用 的 微服 务 化 也 将 市 来 新 的 挑战 ， 其 中 一 个 束 是 把 应 用 划 
分 成 多 个 分 布 式 组 件 运行 ， 每 个 组 件 又 将 进行 集群 化 扩展 ， 组 件 和 组 
件 之 间 的 相互 发 现 和 通信 将 会 变 得 复杂 起 来 ， 而 一 套 服 务 编排 机 制 天 
显得 非常 重要 。 


Kubemetes 提 供 了 强大 的 服务 编排 能 力 ， 微 服务 化 应 用 的 每 一 个 
组 件 都 以 Service 进 行 抽象 ， 组 件 和 组 件 之 间 只 需要 访问 Service 即 可 以 
互相 通信 ， 而 无 须 感知 组 件 的 集群 变化 。 同 时 Kubernetes 为 Service 提 
供 了 服务 发 现 的 能 力 ， 组 件 和 组 件 之 间 可 以 人 简单 地 互相 发 现 。 


Kubernetes 中 支持 两 种 服务 发 现 方法 环境 变量 和 DNS。 


6.4.1 ”环境 变量 


当 有 Pod 被 创建 的 时 候 ，Kubernetes 将 为 Pod 设 置 每 一 个 Service 的 
相关 环境 变量 ， 这 些 环境 变量 包括 两 种 类 型 。 


。Kubernetes Service 环 境 变 量 


Kubemetes 为 Service 设 置 的 环境 变量 形式 ， 包 括 : 


{SVCNAME}_SERVICE_HOST 
{SVCNAME}_SERVICE_PORT 
{SVCNAME}_SERVICE_PORT_{PORTNAME} 


其 中 的 服务 名 和 端口 名 转 为 大 写 ， 连 子 符 转 换 为 下 夯 线 。 


。Docker Link 环 境 变 量 


相当 于 通过 Docker 的 --link 参 数 实现 容器 连接 时 设置 的 环境 
式 ， 可 参考 https:/docs.docker.comyuserguide/dockerlinks/ ° 


比如 现在 有 一 个 Service， 查 询 信 息 如 下 : 


$ kubectl describe service my-dns 
Name: my-dns 

Namespace: default 
Labels: <none> 
Selector: run=my-dns 
Type: ClusterIP 

IP: 10.254.105.183 
Port: dns 53/UDP 
Endpoints: 10.0.10.24:53 
Port: dns-tcp 53/TCP 
Endpoints: 10.0.10.24:53 
Session Affinity: None 


No events. 


# Kubernetes Service 环 境 变量 


这 个 Service 对 应 的 环境 变量 如 下 : 


EH, 


MY DNS SERVICE HOST-10.254.105.183 


MY DNS SERVICE PORT DNS-53 


MY DNS SERVICE PORT DNS TCP-53 


MY DNS SERVICE PORT-53 


4 Docker Link 环 境 变 量 


EH, 


MY DNS PORT 53 UDP PORT-53 


MY DNS PORT 53 TCP ADDR-10.254.105.183 


MY DNS PORT-ugp://10.254.105.183:53 


MY 


DNS. PORT 


53 


MY 


DNS. PORT 


53 


UDP-udp://10.254.105.183:53 
UDP. PROTO-udp 


MY 


DNS. PORT 


53 


UDP ADDR-10.254.105.183 


MY 


DNS. PORT 


53 


TCP PORT-53 


MY 


DNS. PORT 


53 


MY 


DNS. PORT 


53 


TCP-tcp://10.254.105.183:53 
TCP PROTO-tcp 


cI 


可 以 看 到 ， 环 境 变量 中 记录 了 Service 的 虚拟 IP 以 及 端口 和 协议 信 
。 这 样 一 来 ，Pod 中 的 程序 就 可 以 使 用 这 些 环境 变量 发 现 Service ° 


环境 变量 服务 发 现 方式 是 Kubernetes 默 认 文 持 的 ， 但 是 此 种 方式 
存在 限制 。 首 先 环境 变量 是 租户 隅 离 的 ， 即 Pod 只 能 获取 同 Namespace 
中 的 Service 的 环境 变量 。 另 外 ，Pod 和 Service 的 创建 顺序 是 有 要 求 
的 ， 即 Service 必 须 在 Pod 创 建 之 前 被 创建 ， 否 则 Service 环 境 变量 不 会 
设置 到 Pod 中 。DNS 服 务 发 现 方式 则 没有 这 些 限 制 。 


6.4.2 DNS 


DNS 服务 发 现 方式 需要 Kubernetes 提 供 Cluster DNS X: $$, Cluster 
DNS 会 监控 Kubernetes API， 为 每 一 个 Service 创 建 DNS 记录 用 于 域名 解 
析 ， 这 样 在 Pod 中 束 可 以 通过 DNS 域 名 获取 Service 的 访问 地 址 。 而 对 
于 一 个 Service，Cluster DNS 会 创建 两 条 DNS 记 有 杂 : 


[service_name].[namespace_name].[cluster_domain] 


[service name].[namespace name].svc.[cluster domain] 


Cluster DNS 的 安装 方法 可 参考 2.3.1 节 ， 本 书 使 用 的 Cluster DNS 
ServerHJIP7J10.254.10.2, Cluster DNS 的 本 地 域 为 clusterlocal ° 


比如 有 一 个 Service 的 名 称 是 my-service, Namespace 是 my-ns, 
Cluster DNS 会 创建 DNS 记 录 : 


my-service.my-ns.cluster.local 


my-service.my-ns.svc.cluster.local 


对 于 如 何 通过 Cluster DNS 进行 Service 的 域名 解析 ， 需 要 了 解 Linux 
的 DNS 域名 解析 机 制 。Linux 系 统 中 的 DNS 域名 解析 是 通 
过 /etc/resolv.conf 进 行 配置 的 ， 它 的 格式 很 简单 ， 每 行 以 一 个 关键 字 开 
头 ， 后 接 配 置 参 数 。/etc/resolvconf 中 的 相关 关键 字 说 明 如 表 6-1 所 示 。 


表 6-1 /etc/resolv.confK# + 


Ker 说 明 

nameserver DNS 服务 器 的 耳 地址 ， 可 以 有 很 多 行 的 nameserver， 每 一 个 带 一 个 下 地 址 ， 在 查询 
时 就 按 nameserver 在 本 文件 中 的 顺序 进行 

domain 主机 的 域名 ， 当 为 没有 域名 的 主机 进行 DNS 查询 时 使 用 

search DNS 服务 器 搜索 域 ， 它 的 多 个 参数 指明 域名 查询 顺序 。 当 要 查询 没有 域名 的 主机 
时 ， 主 机 将 在 由 search 声 明 的 域 中 分 别 查找 

options DNS 解析 选项 值 ， 以 Key'Value 对 的 方式 出 现 


Pod 中 的 容 絮 使 用 容器 宿主 机 的 DNS 域 名 解析 配置 ， 称 为 默认 
DNS 配置 。 另 外 ， 如 果 Kubernetes 部 署 并 设置 了 Cluster DNS 文 持 ， 那 
么 在 创建 Pod 的 时 候 ， 默 认 会 将 Cluster DNS 的 配置 写 入 Pod 中 容器 的 
DNS 域名 解析 配置 中 ， 称 为 Cluster DNS 配置 。 


比如 ，Kubernetes Node 的 /etc/resolv.conf 配 置 如 下 : 


# Generated by NetworkManager 


nameserver 218.85.157.99 


在 Pod 的 定义 中 通过 .spec.dnsPolicy 设 置 Pod 的 DNS 策略 ， 默 认 值 是 
ClusterFirst ， 查 看 DNS 策略 设置 为 ClusterFirst 的 Pod F 4 g& 


H\J/etc/resolv.conf: 


$ kubectl exec my-app -- cat /etc/resolv.conf 

nameserver 10.254.10.2 

nameserver 218.85.157.99 

search default.svc.cluster.local svc.cluster.local 
cluster.local 


options ndots:5 


其 中 nameserver 10.254.10.2 < Cluster DNS fic E , nameserver 
218.85.157.99 是 容器 宿主 机 的 默认 DNS 配置 。 根 据 先 后 顺序 ， 会 优先 


fit H Cluster DNS 进 行 域名 解析 。 男 外 ， 配 置 中 包括 根据 Pod 的 
Namespace 和 Cluster Domain 设 置 DNS 服务 器 搜索 域 : 


Search [namespace name].svc.[cluster domain] svc. 


[cluster domain] [cluster domain] 


比如 在 Namespace my-ns F HJPodH JDNSHR 4S aa HJT8 RER: 


search my-ns.svc.cluster.local svc.cluster.local cluster.local 


因为 设置 了 DNS Ak 3 ai, 在 Pod 中 就 可 以 使 用 
[service_name].[namespace_name] 访 问 到 任意 Namespace 的 Service， 而 
使 用 [service_name] 可 以 访问 到 同 Namespace 下 的 Service。 比 如 对 于 
Namespace my-ns 下 的 Service my-service ， 任 意 Namespace 的 Pod 通 过 
my-service. my-ns 可 以 解析 发 现 Service: 


$ kubectl exec my-pod -- nslookup my-service.my-ns -- 
namespace=default 
Server: 10.254.10.2 


Address: 10.254.10.2453 


Name: my-service.my-ns.svc.cluster.local 


Address: 10.254.0.235 


[c] Namespace F HJPodn] 以 通过 my-service 解 析 发 现 Service: 


$ kubectl exec my-pod -- nslookup my-service --namespace=my-ns 
Server: 10.254.10.2 


Address: 10.254.10.2453 


Name: my-service.my-ns.svc.cluster.local 


Address: 10.254.0.235 


A>, Cluster DNS 会 为 Headless Service 的 域名 添加 其 Endpoints 的 
所 有 IP， 即 可 以 实现 DNS 的 负载 均衡 : 


$ kubectl describe service my-service 

Name: my-service 

Namespace: default 

Labels: «none» 

Selector: app=nginx 

Type: ClusterIP 

IP: None 

Port: «unnamed» 80/TCP 

Endpoints:  10.0.62.19:80, 10.0.62.20:80, 10.0.62.21:80 
Session Affinity: None 


No events. 


$ kubectl exec my-pod -- nslookup my-service 
Server: 10.254.10.2 


Address: 10.254.10.2453 


Name: my-service.default.svc.cluster.local 
Address: 10.0.62.20 
Name: my-service.default.svc.cluster.local 


Address: 10.0.62.19 


Name: my-service.default.svc.cluster.local 


Address: 10.0.62.21 


65 ”发 布 Service 


Service 的 虚拟 IP 是 由 Kubernetes 虚 拟 出 来 的 内 部 网 络 ， 外 部 网 络 是 
无 法 寻 址 到 的 ， 但 是 有 一 些 Service 又 需要 对 外 暴露 ， 比 如 Web 前 端 。 
这 时 候 就 需要 增加 一 层 网 络 转 发 ， 即 外 网 到 内 网 的 转发 ，Kubernetes 
提供 了 NodePort Service ^ LoadBalancer Service 和 Ingress 可 以 发 布 


Service ° 


6.5.1 NodePort Service 


NodePort Service 是 类 型 为 NodePort 的 Service，Kubernetes 除 了 会 分 
配给 NodePort Service 一 个 内 部 ABUTERE Node LAR 
端口 NodePort， 外 部 网 络 可 以 通过 [NodeIP]:JNodePort] 访 问 到 Service ° 


我 们 现在 创建 一 个 NodePort Service: 


apiVersion: vi 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 

- name: http 
port: 80 
targetPort: 80 
protocol: TCP 


type: NodePort 


创建 成 功 后 查询 NodePort Service: 


$ kubectl describe service my-nginx 
Name: my -nginx 
Namespace: default 
Labels: <none> 
Selector: app=nginx 
Type: NodePort 

IP: 10.254.38.180 
Port: http 80/TCP 
NodePort: http 32143/TCP 
Endpoints: <none> 
Session Affinity: None 


No events. 


可 以 看 到 ，Kubernetes 给 NodePort Service 中 每 一 个 端口 都 创建 了 
一 个 NodePort (http 32143/TCP) ， 在 NodePort Service 定 义 中 可 以 通 
过 .spec.ports[].nodePort 指 定 固定 NodePort ，NodePort 的 范围 默认 是 
30000-32767, ， 可 以 通过 Kubernetes API Server 的 启动 参数 --service- 


node-port-range 指 定 范 围 。 


NodePort Service Wt HJ LA iÑ 3X [NodeIP]:[NodePort] ij |H] , mi 4 
NodelP 是 一 个 公 网 IP 时 ， 外 部 就 可 以 访问 到 NodePort Service 了。 


6.5.2 LoadBalancer Service 


LoadBalancer Service 是 类 型 “4 LoadBalancer 的 Service , 
LoadBalancer Service 是 建立 在 NodePort Service 集 群 上 的 ，Kubernetes 会 
分 配给 LoadBalancer Service— ^ NÄRA EIP, Jf H.a&8&NodePort ° 
ERILZL PM, Kubernetesi$ KREZ & 8$ —^ AE us. CERES 
Node 作 为 后 端 ， 负 载 均 衡器 将 转发 请 求 到 [NodeIP]:[NodePort] ° 


LoadBalancer Service 需 要 瓜 层 云 平台 支持 创建 负载 均衡 器 ， 比 如 
GCE， 现 在 创建 一 个 LoadBalancer Service: 


apiVersion: vi 
kind: Service 
metadata: 

name: my-nginx 
spec: 

selector: 


app: nginx 


ports: 
- name: http 
port: 80 


targetPort: 80 


protocol: TCP 


type: LoadBalancer 


Kubernetes 2: 47 824 LoadBalancer Service 一 个 内 部 的 虚拟 卫 ， 并 且 
又 露 NodePort。 进 一 步 鸭 ，Kubernetes 请 求 底 层 云 平台 创建 一 个 负载 均 
衡器 ， 作 为 访问 LoadBalancer Service 的 外 部 访问 入 口 。 负 载 均 衡 絮 由 
故 层 云 平 台 创 建 提供 ， 会 包含 一 个 LoadBalancerIP， 可 以 认为 是 


LoadBalancer Service 的 外 部 IP， 查 询 LoadBalancer Service: 


$ kubectl get svc my-nginx 

NAME CLUSTER_IP EXTERNAL_IP PORT(S) 
SELECTOR AGE 

my -nginx 10.254.147.57 78.110.25.19 80/TCP 


app=nginx 4m 


其 中 EXTERNAL IP:78.110.25.19 4 LoadBalancer Service 的 外 部 
IP。 负 载 均 衡器 将 每 个 Node 作 为 后 端 ， 当 请 求 78.110.25.19:80 时 ， 负 
载 均衡 器 将 转发 请 求 到 相应 的 [NodeIP]:[NodePort]， 从 而 访问 到 


LoadBalancer Service ° 


6.5.3 Ingress 


Kubernetes 提 供 了 一 种 HTTP 方 式 的 路 由 转发 机 制 ， 称 为 mgress。 
Ingress 的 实现 需要 两 个 组 件 文 持 ，Ingress Controller 和 HTTP 代 理 服务 
磊 。HTTP 代 理 服 务 顺 将 会 转发 外 部 的 HITP 请 求 到 Service fii Ingress 
Controller 则 需要 监控 Kubernetes API， 实 时 更 新 HTTP 代 理 服务 絮 的 转 
发 规则 。 


提示 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Ingress 处 于 beta 测 试 阶 


EY © 


我 们 现在 创建 一 个 mgress，Ingress 的 定义 文件 my-ingress.yaml: 


apiVersion: extensions/vibetai 
kind: Ingress 
metadata: 
name: my-ingress 
spec: 
rules: 
- host: my.example.com 
http: 
paths: 
- path: /app 
backend: 
serviceName: my-app 


servicePort: 80 


Ingress 定义 中 的 .spec.rules 设置 了 转发 规则 ， 其 中 配置 了 一 条 规 
MJ, = HTTP 请 求 的 host 为 myexample.com 且 path 为 /app 时 ， 转 发 到 
Service my-appH‘J80%i 1 ° 


通过 定义 文件 创建 Ingress: 


$ kubectl create -f my-ingress.yaml 


ingress "my-ingress" created 


创建 成 功 后 可 以 查询 Ingress: 


$ kubectl get ingress my-ingress 
NAME RULE BACKEND ADDRESS 
my-ingress - 

my.example.com 


/app my -app:80 


4 DR ， 需 要 Ingress 人 配置 ， 
设置 HTTP 代 理 服务 器 的 转发 策略 ， 外 部 通过 HTTP 代 理 服 务 器 就 可 以 
访问 到 Service ° 


在 当前 版 本 (Kubernetes v1.1.1) "P, Ingress Controller 和 HTTP 代 
理 服 务 器 是 作为 外 部 组 件 运行 的 。 官 方 提 供 了 GCE Load-Balancer 作 为 
HTTP 代 理 服 务 右 ， 另 外 也 可 以 使 用 HAProxy 或 者 Nginx 等 开源 方案 。 


以 Nginx 为 例 ， 将 Nginx 配 置 文件 以 模板 形式 编写 : 


const ( 
nginxConf = ^ 

events { 

worker_connections 1024; 
} 
http { 
((range $ing := .Items}} 
{{range $rule :- $ing.Spec.Rules}} 


server { 
listen 80; 
server name {{$rule.Host}}; 
resolver 127.0.0.1; 
{{ range $path := $rule.HTTP.Paths }} 
location {{$path.Path}} { 
proxy pass http://{{$path.Backend.ServiceName}}: 
{{$path.Backend.ServicePort}}; 
t{{end} } 
s{{end} }{{end} } 
$5 
) 


Ingress Controllers #Kubernetes API: 


for { 
rateLimiter.Accept() 
ingresses , err :- ingClient.List(labels.Everything(). 
fields.Everything()) 
if err !- nil || reflect.DeepEqual(ingresses.Items , 


known.Items) { 


continue 
} 
if w, err := os.Create("/etc/nginx/nginx.conf"); err != 
nil { 
log.Fatalf("Failed to open %v: %v", nginxConf, err) 


} else if err := tmpl.Execute(w, ingresses); err != nil { 


log.Fatalf("Failed to write template %v", err) 


} 
shellOut("nginx -s reload") 


最 终生 成 的 Nginx 配 置 文件 如 下 : 


events { 
worker_connections 1024; 
} 
http { 
server { 
listen 80; 
server_name my.example.com; 


resolver 127.0.0.1; 


location /app { 


proxy pass http://my-app: 80; 


这 样 一 来 ，Nginx 将 作为 访问 入 口 ， 访 问 http://my.example.com/app 
的 请 求 将 会 转发 到 http://my-app:80， 即 访问 到 Service ° 


第 7 章 
数据 卷 


数据 卷 用 于 实现 容器 持久 化 数据 ，Kubernetes 对 于 数据 郑重 狐 定 
X 提供 了 丰富 强大 的 功能 。 本 章 将 数据 卷 按 照 功能 划分 为 三 类 : 本 
地 数据 卷 、 网 络 数据 卷 和 信息 数据 卷 ， 并 一 一 进行 说 明 ， 包 括 使 用 方 
法 、 配 置 参 数 和 示例 。 男 外 ， 其 中 结合 示例 详细 介绍 了 Persistent 


Volume 和 了 Persistent Volume Claim ° 


7.1 ”Kubernetes 数 据 卷 


在 Docker 的 设计 实现 中 ， 容 万 中 的 数据 是 临 时 的 ， 即 当 容 融 被 销 
驱 时 ， 其 中 的 数据 将 会 丢失 。 如 有 果 需 要 持久 化 数据 ， 需 要 使 用 Docker 
AR Ttt EP LER SC PESCE H ORI dE n 


在 Kubernetes 系 统 中 ， 当 Pod 重 建 的 时 候 ， 数 据 是 会 丢失 的 ， 
Kubernetes 也 是 通过 数据 卷 来 提供 Pod 数 据 的 持久 化 的 。Kubernetes 数 据 
卷 是 对 Docker 数 据 卷 的 扩展 ，Kubernetes 数 据 卷 是 Pod 级 别 的 ， 可 以 用 
来 实现 Pod 中 容器 的 文件 共享 。 


Kubernetes 数 据 卷 适 配 对 接 各 种 存储 系统 ， 提 供 了 丰富 强大 的 功 
能 。Kubernetes 提 供 了 以 下 类 型 的 数据 卷 : 


* EmptyDir 


* HostPath 


* GCE Persistent Disk 

* Aws Elastic Block Store 
e NFS 

e iSCSI 

* Flocker 

* GlusterFS 

* RBD 

* Git Repo 

e Secret 

* Persistent Volume Claim 


* Downward API 


7.2 ”本 地 数据 卷 


Kubernetes 中 有 两 种 类 型 的 数据 着 ， 它 们 只 能 作用 于 本 地 文件 系 
统 ， 我 们 称 为 本 地 数据 卷 。 本 地 数据 卷 中 的 数据 只 会 存在 于 一 台 机 夷 
上 上， 所 以 当 Pod 发 生 了 迁移 的 时 候 ， 数 据 便 会 丢失 ， 无 法 满足 真正 的 数据 
持久 化 要 求 。 但 是 本 地 数据 卷 握 供 了 其 他 用 途 ， 比 如 Pod 中 容 夯 的 文件 
共享 ， 或 者 共享 入 主机 的 文件 系统 。 


7.2.1 EmptyDir 


EmptyDir 从 名 称 上 的 意思 看 是 空 的 目录 ， 它 是 在 Pod 创 建 的 时 候 新 
建 的 一 个 目录 。 


如 条 Pod 配 置 了 EmptyDir 数 据 卷 ， 在 Pod 的 生命 周期 内 都 会 存在 ， 
当 Pod 被 分 配 到 Node 上 的 时 候 ， 会 在 Node 上 创建 EmptyDir 数 据 卷 ， 并 
挂 载 到 Pod 的 容器 中 。 只 要 Pod 存 在 ，EmptyDir 数 据 卷 都 会 存在 (容器 
删除 不 会 导致 EmptyDir 数 据 卷 丢失 数据 ) ， 但 是 如 果 Pod 的 生命 周期 终 
结 〈Pod 被 删除 ) ，EmptyDir 数 据 卷 也 会 被 删除 ， 并 且 永 久 丢 失 。 


EmptyDir 数 据 卷 非 常 适合 实现 Pod 中 容器 的 文件 共享 。Pod 的 设计 
提供 了 一 个 很 好 的 容器 组 合 的 模型 ， 容 器 之 间 各 司 其 职 ， 通 过 共享 文 
件 目 邓 来 完成 交互 ， 比 如 可 以 通过 一 个 专职 日 志 收 集 容 右 ， 在 每 个 Pod 
中 和 业务 容器 中 进行 组 合 ， 来 完成 日 志 的 收集 和 汇 忌 。 


我 们 创建 一 个 Pod，Pod 中 包含 两 个 容器 ， 容 器 synthetic-logger 写 日 
志 到 /var/log 目 录 ， 而 容器 sidecar-log-collector 人 负责 收 集 /var/log 日 a 
日 志文 件 ， 然 后 导出 到 Elasticsearch ， 其 中 的 /vavlog 目 孙 就 是 一 
EmptyDir 数 据 卷 ， 分 别 挂 载 到 两 个 容器 中 从 而 实现 文件 共享 。 P 
定义 文件 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 
labels: 
example: logging-sidecar 


name: logging-sidecar-example 


spec: 
containers: 
- name: synthetic-logger 
image: ubuntu:14.04 
command: ["bash","-c","i=\"O\"; while true; do 
\"*hostname’>: $i \" >> 
/var/log/synthetic-count.1log; date --rfc-3339 ns 
/var/log/synthetic-dates.log; sleep 4; 
i=$[$i+1]; done"] 
volumeMounts: 
- name: log-storage 
mountPath: /var/log 
- name: sidecar-log-collector 
image: gcr.io/google containers/fluentd-sidecar-es:1.2 
resources: 
limits: 
cpu: 100m 
memory: 200Mi 
env: 


- name: FILES TO COLLECT 


echo 


22 


value: "/var/log/synthetic-count.log /var/log/synthetic- 


dates.log" 
volumeMounts: 
- name: log-storage 
readOnly: true 
mountPath: /var/log 


volumes: 


- name: log-storage 


emptyDir: {} 


7.2.2 HostPath 


HostPath 数 据 卷 允许 将 容器 答 主 机 上 的 文件 系统 挂 载 到 Pod 中 。 如 
果 Pod 需 要 使 用 宿主 机 上 的 某 些 文件 ， 可 以 使 用 HostPath 数 据 卷 。 


创建 一 个 Pod 需 要 使 用 宿主 机 的 SSL 证 书 ， 可 以 通过 创建 HostPath 
数据 卷 ， 然 后 将 特 主 机 的 /etc/sslycerts 目 孙 挂 载 到 容 句 中 ，Pod 的 定义 文 
件 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
protocol: TCP 
volumeMounts: 
- name: ssl-certs 
mountPath: /etc/ssl/certs 


readOnly: true 


volumes: 
- name: ssl-certs 
hostPath: 


path: /etc/ssl/certs 


7.3 ”网 络 数据 着 


Kubernetes 提 供 了 很 多 类 型 的 数据 卷 以 集成 第 三 方 的 存储 系统 ， 包 
括 一 些 非常 流行 的 分 布 式 文件 系统 ， 也 有 在 IaaS 平 台 上 提供 的 存储 文 
持 ， 这 些 存储 系统 都 是 分 布 式 的 ， 通 过 网 络 共 至 文件 系统 ， 因 此 我 们 
称 这 一 类 数据 卷 为 网 络 效 据 着 。 


网 络 数据 卷 能 够 满足 数据 的 持久 化 需求 ，Pod 通 过 配置 使 用 网 络 数 
据 卷 ， 每 次 Pod 创 建 的 时 候 都 会 将 存储 系统 的 远 端 文件 目录 挂 载 到 容 咽 
中 ， 数 据 卷 中 的 数据 将 被 永久 保存 ， 即 使 Pod 被 删除 的 时 候 ， 只 是 除去 
挂 载 数据 着， 数据 卷 中 的 数据 仍然 保存 在 存储 系统 中 ， 并 且 当 新 的 Pod 
被 创建 的 时 候 ， 仍 是 挂 载 同样 的 数据 卷 。 


7.3.1 NES 


NFS (Network File System) 即 网 络 文件 系统 ， 是 FreeBSD 文 持 的 
一 种 文件 系统 ， 它 允许 网 络 中 的 计算 机 通过 TCP/IP 共 享 资源 。 在 NFS 的 
应 用 中 ， 本 地 NFS 的 客户 端 应 用 可 以 透明 地 读 写 位 于 远 端 NFS 服 务 硕 上 
的 文件 ， 残 像 访 问 本 地 文件 一 样 。 


NFS 数 据 卷 的 配置 参数 如 表 7-1 所 示 。 


表 7-1 NFS 数 据 卷 的 配置 参数 


1 说 明 


server T NEFS 的 服务 端 地 址 
path AG NEFS 的 共享 目录 路 径 


ER AI, RAUN 


readOnly 是 false 〈 即 可 读 可 
写 ) 。 
示例 如 下 : 
apiVersion: v1 
kind: Pod 
metadata: 


name: nfs-web 
spec: 
containers: 
- name: web 
image: nginx 
ports: 
- name: web 
containerPort: 80 
volumeMounts: 
- name: nfs 


mountPath: "/usr/share/nginx/html" 


volumes: 
- name: nfs 
nfs: 
server: nfs-server.default.kube.local 


path: "/" 


7.3.2 iSCSI 


iSCSI 技术 是 一 种 由 IBM 公 司 研究 开发 的 ， 是 一 个 供 硬件 设备 使 用 
的 可 以 在 IP 的 上 层 运行 的 SCSI 指 令 集 ， 这 种 指令 集合 可 以 实现 在 IP 网 
络 上 运行 SCSI 协 议 ， 使 其 能 够 在 诸如 高 速 千 兆 以 太 网 上 进行 路 由 选 
择 。iSCSI 技 术 是 一 种 新 的 储存 技术 ， 该 技术 是 将 现 有 SCSI 接 口 与 以 太 
网 络 (Ethernet) 技术 结合 ， 使 服务 器 可 与 使 用 IP 网 络 的 储存 装置 互相 
交换 资料 。 


iSCSI 数据 卷 的 配置 参数 如 表 7-2 所 示 。 


表 7-2 iSCSI 数据 卷 配 置 参数 


参数 


[d 
= 


说 明 

iSCSI Target 服 务 地 址 

iSCSI 的 IJQN 号 

iSCSI 的 逻辑 单元 号 

文件 系统 类 型 ，ext4、xfs 或 ntfs 
是 否 只 读 ， 默 认为 false( 即 可 读 可 写 ) 


targetPortal 


A | OX | OA | OA] mA. 


示例 如 下 : 


apiVersion: vi 


kind: Pod 


metadata: 
name: iscsipd 
spec: 
containers: 
- image: kubernetes/pause 
name: iscsipd-ro 
volumeMounts: 
- mountPath: /mnt/iscsipd 
name: iscsipd-ro 
- image: kubernetes/pause 
name: iscsipd-rw 
volumeMounts: 
- mountPath: /mnt/iscsipd 
name: iscsipd-rw 
volumes: 
- iscsi: 
fsType: ext4 
ign: iqn.2001-04.com.example:storage.kube.sys1. xyz 
lun: 0 
readOnly: true 
targetPortal: 10.0.2.15:3260 
name: iscsipd-ro 
- iscsi: 
fsType: ext4 
ign: iqn.2001-04.com.example:storage.kube.sys1. xyz 


lun: 1 


targetPortal: 10.0.2.15:3260 


name: iscsipd-rw 


7.3.3 GlusterFS 


GlusterFS 是 Scale-Out 存 储 解 决 方案 Gluster 的 核心 ， 它 是 一 个 开源 
的 分 布 式 文件 系统 ， 具 有 强大 的 横向 扩展 能 力 ， 通 过 扩展 能 够 文 持 数 
PB 存储 容量 和 处 5 T&F 9m e GlusterFS fë EJ TCP/IP EX InfiniBand 
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则 来 管理 数据 。GlusterFS 基 于 可 堆 著 的 用 户 空 间 设 计 ， 可 为 各 种 不 同 
的 数据 负载 提供 优异 的 性 能 。 


GlusterFS 数 据 卷 配置 参数 如 表 7-3 所 示 。 


37-3 GlusterFS 数据 卷 配置 参数 


参数 可 选项 说 明 


dec zs GlusterFS 服 务 端 对 应 
endpoints T 
i B 的 Endpoint 


path GlusterFS 数 据 卷 路 径 


是 否 只 读 ， 默 认为 
false ( 即 可 读 可 写 ) 


readOnly 是 


示例 如 下 : 


apiVersion: vi 
kind: Endpoints 
metadata: 
name: glusterfs-cluster 
subsets: 
- addresses: 


- ip: 10.240.106.152 


ports: 
- port: 1 
- addresses: 


- ip: 10.240.79.157 

ports: 

- port: 1 

apiVersion: vi 
kind: Pod 
metadata: 

name: glusterfs 

spec: 

containers: 

- image: kubernetes/pause 
name: glusterfs 
volumeMounts: 

- mountPath: /mnt/glusterfs 
name: glusterfsvol 
volumes: 


- glusterfs: 


endpoints: glusterfs-cluster 
path: kube_vol 
readOnly: true 


name: glusterfsvol 


7.3.4 RBD (Ceph Block Device) 


Ceph 是 开源 、 分 布 式 的 网 络 存储 ， 同 时 又 是 文件 系统 。Ceph 的 设 
计 目 标 是 卓越 的 性 能 、 可 靠 性 以 及 可 扩展 性 。Ceph 基 于 可 靠 的 、 可 扩 
展 的 和 分 布 式 的 对 象 存 储 ， 通 过 一 个 分 布 式 的 集群 管理 元 数据 ， 符 合 
POSIX ° RBD (Rados Block Device) 是 一 个 Linux 块 设备 驱动 ， 提 供 了 
一 个 共享 网 络 块 设 备 ， 实 现 与 Ceph 的 交互 。RBD 在 Ceph 对 象 存储 的 集 
群 上 进行 条 带 化 和 复制 ， 提 供 可 靠 性 、 可 扩展 性 以 及 对 块 设 备 的 访 
问 。 


Kubernetes 中 支持 RBD 方 式 ，RBD 数 据 卷 配 置 的 参数 如 表 7-4 所 
未。 
表 7-4 ”RBD 数 据 卷 配置 参 数 


参数 i 说 明 

monitors N Ceph Monitors 的 地 址 

image E Rados 镜像 名 称 

fsType H 文件 系统 类 型 ，ext4、xfs 或 ntfs 


pool 3 Rados Pool 名 称 ， 默 认 是 rbd 

user Rados 用 户 名 ， 默 认 是 admin 

keyring Rados 钥 是 圈 文 件 的 路 径 ， 默 认为 /etc/cephy/keyring 
secretRef : Rados 用 户 认证 Secret， 默 认为 空 

readOnly 是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 


示例 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: rbd 
spec: 
containers: 
- image: kubernetes/pause 
name: rbd-rw 
volumeMounts: 


- mountPath: /mnt/rbd 


name: rbdpd 
volumes: 
- name: rbdpd 
rbd: 


fsType: ext4 

image: foo 

keyring: /etc/ceph/keyring 
monitors: 

- 10.16.154.78:6789 

- 10.16.154.82:6789 

- 10.16.154.83:6789 

pool: kube 

readOnly: true 


user: admin 


7.3.5 Flocker 


Flocker 是 一 个 容 絮 数据 管理 工具 ， 作 为 ClusterHQ 公 司 2014 年 推出 

的 产品 ，Flocker 主 要 负责 Docker 容 右 及 其 数据 的 管理 。 从 功能 方面 而 

言 ，Flocker 是 一 个 数据 卷 管 理 右 和 多 主机 的 Docker 集 群 管理 工具 。 用 

户 可 以 通过 它 来 控制 数据 ， 实 现在 Docker 中 运行 数据 库 、 队 列 和 键 值 
(Key/Value) 存储 等 服务 ， 并 在 应 用 程序 中 轻松 使 用 这 些 服务 。 


Flocker 数 据 卷 配置 参数 如 表 7-5 所 示 。 


表 7-5 Flocker 数据 卷 配置 参数 


参数 可 选项 说 明 
datasetName T Flocker 数 据 集 名 称 


示例 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: flocker-web 
spec: 

containers: 

- name: web 
image: nginx 
ports: 

- name: web 
containerPort: 80 


volumeMounts: 


# name must match the volume name below 
- name: www-root 
mountPath: "/usr/share/nginx/html" 
volumes: 
- name: www-root 
flocker: 


datasetName: my-flocker-vol 


7.3.6 AWS Elastic Block Store 


Amazon Elastic Block Store (Amazon EBS) 在 AWS 云 中 提供 用 于 
Amazon EC2 实 例 的 持久 性 数据 的 块 级 存储 卷 。 如 果 Kubernetes 运 行 在 
AWS 之 上 ， 束 可 以 非常 方便 地 使 用 Amazon Elastic Block Store 作 为 数据 
FR o 


Amazon Elastic Block Store 数 据 卷 的 配置 参数 如 表 7-6 所 示 。 


327-6 Amazon Elastic Block Store 数 据 卷 配 置 参 数 


参数 i 说 明 
volumeID X EBS 数 据 卷 标 识 


fsType S 文件 系统 类 型 ，ext4、xfs 或 ntfs 
partition 是 磁盘 挂 载 分 区 
readOnly : 是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 


示例 如 下 : 


apiVersion: vi 
kind: Pod 


metadata: 


name: test-ebs 
spec: 
containers: 
- image: gcr.io/google containers/test-webserver 
name: test-container 
volumeMounts: 
- mountPath: /test-ebs 
name: test-volume 
volumes: 
- name: test-volume 
# This AWS EBS volume must already exist. 
awsElasticBlockStore: 
volumeID: aws://<availability-zone>/<volume -id> 


fsType: ext4 


7.3.7 GCE Persistent Disk 


GCE Persistent Disk @ GCE 提供 的 持久 化 数据 的 服务 ， 如 果 
Kubernetes 运 行 在 GCE 之 上 ， 可 以 使 用 GCE Persistent Disk 作 为 数据 卷 。 


GCE Persistent Disk 数 据 卷 的 配置 参数 如 表 7-7 所 示 。 


表 7-7 GCE Persistent Disk 数 据 卷 配置 参数 


参数 i 说 明 

volumeID EBS 数 据 卷 标识 

fsType 7 文件 系统 类 型 ，ext4、xfs 或 ntfs 
partition 是 磁盘 挂 载 分 区 

readOnly : 是 否 只 读 ， 默 认为 false〈 即 可 读 可 写 ) 


示例 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: test-pd 

spec: 

containers: 

- image: gcr.io/google containers/test-webserver 
name: test-container 
volumeMounts: 

- mountPath: /test-pd 
name: test-volume 

volumes: 

- name: test-volume 
# This GCE PD must already exist. 
gcePersistentDisk: 

pdName: my-data-disk 


fsType: ext4 


7.4 Persistent Volume 和 Persistent 
Volume Claim 


理解 每 个 存储 系统 是 一 件 复杂 的 事情 ， 特 别 是 对 于 普通 用 户 来 
说 ， 有 时 候 并 不 关心 各 种 存储 实现 ， 只 硕 望 能 够 安全 可 靠 地 存储 数 
据 。Kubernetes 中 提供 了 Persistent Volume fll Persistent Volume Claim 机 


制 ， 这 是 存储 消费 模式 。Persistent Volume 是 由 系统 管理 员 配 置 创 建 的 
一 个 数据 卷 ， 它 代表 了 某 一 类 存储 插件 实现 ， 可 以 是 NFS、iSCSI 等 ; 
而 对 于 普通 用 户 来 说 ， 通 过 Persistent Volume Claim 可 请 求 并 获得 合适 
的 Persistent Volume， 而 无 须 感知 后 端的 存储 实现 。 


Persistent Volume Claim 和 Persistent Volume 的 关系 其 实 类 似 于 Pod 和 
Node，Pod 消 费 Node 的 资源 ，Persistent Volume Claim 则 是 消费 Persistent 
Volume 的 资源 。Persistent Volume 和 了 Persistent Volume Claim TH &. X: EK , 
有 着 完整 的 生命 周期 管理 。 


* 准备 


系统 管理 员 规划 并 创建 一 系列 的 Persistent Volume, Persistent 
Volume 在 创建 成 功 后 处 于 可 用 状态 。 


“ 绑 定 


用 户 创建 Persistent Volume Claim 来 声明 存储 请 求 ， 包 括 存储 
大 小 和 访问 模式 。Persistent Volume Claim 创 建成 功 后 进入 等 待 状 
态 ， 当 Kubernetes 发 现 有 新 的 Persistent Volume Claim 创 建 的 时 候 ， 
就 会 根据 条 件 查找 Persistent Volume。 当 有 Persistent Volume 匹 配 的 
TIE, mL Persistent Volume Claim fll Persistent Volume 进 行 绑 
4E, Persistent Volume 和 Persistent Volume Claim 都 进入 绑 定 状态 。 


Kubernetes 只 会 选择 可 用 状态 的 Persistent Volume， 并 且 采 取 最 小 满 
足 策 略 ， 而 当 没 有 Persistent Volume 满 足 需求 的 时 候 ，Persistent Volume 


Claim 将 处 于 等 待 阶段 。 比 如 现在 有 两 个 Persistent Volumen] Hj, —~* 


Persistent Volume 的 容量 是 50Gi， 一 个 Persistent Volume 的 容量 是 60Gi ° 


那么 请 求 40Gi 的 Persistent Volume Claim 会 被 绑 定 到 50Gi 的 Persistent 
Volume， 而 请 求 100Gi 的 Persistent Volume Claim 则 处 于 等 待 状态 ， 直 到 
有 大 于 100Gi 的 Persistent Volume 出 现 (Persistent Volume 有 可 能 被 新 建 
或 者 被 回收 ) 。 


- 使 用 


创建 Pod 的 时 候 使 用 Persistent Volume Claim ，Kubernetes 便 会 
查询 其 绑 定 的 Persistent Volume， 去 调用 真正 的 存储 实现 ， 然 后 将 
数据 卷 挂 载 到 Pod 中 。 


* 释放 


当 用 户 删 除 Persistent Volume it 3E HJ Persistent Volume Claim 
If, Persistent Volume 则 进入 释放 状态 。 此 时 Persistent Volume nT 
能 残留 着 之 前 Persistent Volume Claim 使 用 的 数据 ， 所 以 Persistent 
Volume 并 不 可 用 ， 需 要 对 Persistent Volume 进 行 回 收 探 作 。 


« 回收 


释放 的 Persistent Volume 需 要 回收 才能 再 次 使 用 ， 回 收 的 策略 
可 以 是 人 工 处 理 ， 或 者 由 Kubernetes 自 动 进行 清理 ， 如 清理 失败 ， 


Persistent Volume 会 进入 失败 状态 。 
综 上 所 述 ，Persistent Volume 的 状态 包括 如 下 几 项 。 


e Available: Persistent Volume 创 建成 功 后 进入 可 用 状态 ， 等 待 
Persistent Volume Claim 消 费 。 


* Bound: Persistent Volume 被 分 配 到 Persistent Volume Claim 进 行 绑 
^E, Persistent Volume 进 入 绑 定 状态 。 


e Released: Persistent Volume 绑 定 的 Persistent Volume Claim # Hf] 
KR, Persistent Volume 进 入 释放 状态 ， 等 待 回 收 处 理 o 


* Failed: Persistent Volume 执行 目 动 清理 回收 策略 失败 后 ， 
Persistent Volume 会 进入 失败 状态 。 


Persistent Volume Claim 的 状态 包括 如 下 几 项 。 


。Pending: Persistent Volume Claim 创 建成 功 后 进入 等 待 状态 ， 等 和 
28 E Persistent Volume ° 


e Bound: 4} fd Persistent Volume Zs Persistent Volume Claim 进行 绑 
^E, Persistent Volume Claim ABBE IKA ° 


7.4.1 Persistent Volume 


Persistent Volume 代 表 可 靠 的 存储 系统 ， 从 实现 上 来 说 ，Persistent 
Volume 实 际 上 了 吏 是 复 用 了 已 有 的 数据 卷 实现 ， 配 置 方法 也 是 一 致 鸭 ， 
Persistent Volume 目 前 文 持 以 下 类 型 


* GCE Persistent Disk 

* AWS Elastic Block Store 

e NFS 

* iSCSI 

* RBD (Ceph Block Device) 
* GlusterFS 


e HostPath: 只 适合 测试 使 用 


Persistent Volume 是 需要 事先 创建 好 的 ， 这 一 般 来 说 是 系统 管理 员 
的 工作 。 系 统管 理 员 根据 实际 情况 ， 创 建 一 系列 可 用 的 Persistent 
Volume。 比 如 Kubernetes 是 运行 在 AWS 之 上 的 ， 购 买 了 10 个 100Gi 的 
AmazonEBS， 那 就 可 以 创建 10 个 容量 为 100Gi 的 Persistent Volume ° 


创建 Persistent Volume 的 时 候 需 要 指定 数据 卷 的 容量 、 访 问 模式 和 
回收 集 上 略 。 


* 容量 


Persistent Volume 通 过 设置 资源 容量 ， 然 后 Persistent Volume Claim 
在 请 求 的 时 候 指 定 资源 需求 来 进行 匹配 。 比 如 现在 有 1 个 容量 为 10Gi 的 
Persistent Volume 和 1 个 容量 为 20Gi 的 Persistent Volume ， Persistent 
Volume Claim i$ 2K 15Gi, Wi VE Ad Y 20Gi AY Persistent Volume ° 目前 
Persistent Volume ARRERA — 1 ESTE, METAAN: 


Capacity: 


storage: 20Gi 


. 访问 模式 


e ReadWriteOnce: 数据 卷 能 够 在 一 个 节点 上 挂 载 为 读 写 日 


录 。 

* ReadOnlyMany: 数据 卷 能 够 在 多 个 和 点 上 挂 载 为 只 读 目 
FE 。 

e ReadWriteMany: 数据 卷 能 够 在 多 个 下 点 上 挂 载 为 读 写 目 
FE 。 


© 回收 策略 


当前 文 持 的 回收 集 略 如 下 所 示 。 


e Retain: Persistent Volume 在 释放 后 ， 需 要 人 工 进 行 回 收 操 
作 。 

e Recycle: Persistent Volume 在 释放 后 ，Kubemetes 目 动 进行 清 
理 ， 清 理 成 功 后 Persistent Volume 则 可 以 再 次 绑 定 使 用 。 目 前 只 有 
NFS 和 HostPath 类 型 的 Persistent Volume 支 持 回收 策略 。 当 执行 回收 
策略 的 上 时候 ， 会 创建 一 个 Persistent Volume Recycler Pod， 这 个 Pod 
执行 清理 动作 ， 即 删除 Persistent Volume 目 录 下 的 所 有 文件 (包括 
隐藏 文件 ) 


现在 创建 一 个 Persistent Volume, Persistent Volume 的 定义 文件 nfs- 
pv.yaml: 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: nfs-pv 
labels: 
type: nfs 
spec: 
capacity: 
storage: 56i 
accessModes: 
- ReadwriteMany 
nfs: 
server: nfs-server 


path: / 


Persistent Volume 的 定义 中 使 用 了 NFS， 配 置 参数 同 NFS 数 据 卷 一 
致 ， 另 外 设置 了 存储 容量 为 5Gi， 访 问 权 限 为 ReadWriteMany。 


通过 定义 文件 创建 Persistent Volume: 


$ kubectl create -f nfs-pv.yaml 


persistentvolume "nfs-pv" created 


创建 成 功 后 可 以 查询 创建 的 Persistent Volume, Persistent Volume 的 
状态 为 Available: 


$ kubectl describe persistentvolume nfs-pv 
Name: nfs-pv 
Labels: type=nfs 
Status: Available 
Claim: 
Reclaim Policy: Retain 
Access Modes: RWX 
Capacity: 5Gi 
Message: 
Source: 
Type: NFS (an NFS mount that lasts the lifetime of a pod) 
Server :nfs-server 
Path: / 
ReadOnly: false 


7.4.2 €f Persistent Volume Claim 


Persistent Volume Claim 指 定 所 需要 的 存储 大 小 ， 然 后 Kubernetes 会 
选择 满足 条 件 的 Persistent Volume 进 行 绑 定 。 


现在 创建 Persistent Volume Claim 来 消费 刚 创 建 的 Persistent 
Volume, Persistent Volume Claim 的 定义 文件 test-pvc.yaml: 


apiVersion: vi 
kind: PersistentVolumeClaim 
metadata: 


name: test-pvc 


spec: 
accessModes: 
- ReadwriteMany 
resources: 
requests: 


storage: 3Gi 


通过 定义 文件 创建 Persistent Volume Claim: 


$ kubectl create -f my-pvc.yaml 


persistentvolumeclaim "my-pvc" created 


创建 成 功 后 可 以 查询 创建 的 Persistent Volume Claim: 


$ kubectl describe persistentvolumeclaim my-pvc 
Name:  my-pvc 
Namespace: default 


Status: Bound 


Volume: nfs-pv 
Labels: «none» 
Capacity: 56i 


Access Modes: RWX 


A] LAA eI), Persistent Volume Claim ©2248 E Persistent Volume 为 
nfs-pv， 然 后 查询 Persistent Volume 的 状态 为 Bound: 


$ kubectl describe persistentvolume nfs-pv 
Name: nfs-pv 


Labels: type=nfs 


Status: Bound 
Claim: default/my-pvc 
Reclaim Policy: Retain 
Access Modes:  RWX 
Capacity: 5Gi 
Message: 
Source: 
Type: NFS (an NFS mount that lasts the lifetime of a pod) 
Server :nfs-server 
Path: / 
ReadOnly: false 


最 后 创建 Pod 来 使 用 Persistent Volume Claim，Pod 的 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 

labels: 
app: busybox 

spec: 

containers: 

- name: busybox 
image: busybox 
command: 

- sleep 
- 3600 


volumeMounts: 


- mountPath: /busybox-data 
name: data 
volumes: 
- name: data 
persistentVolumeClaim: 


claimName: my-pvc 


7.5 “信息 数据 卷 


Kubernetes 中 有 一 些 数 据 卷 ， 主 要 用 来 给 容 絮 传递 配置 信息 ， 我 们 
称 之 为 信息 数据 卷 ， 比 如 Secret 和 Downward API， 都 是 将 Pod 的 信息 以 
文件 形式 保存 ， 然 后 以 数据 卷 方式 挂 载 到 容 絮 中 ， 容 右 通 过 读 取 文件 
获取 相应 的 信息 。 从 功能 设计 上 来 说 ， 是 有 点 偏离 数据 卷 的 本 意 ， 数 
据 卷 是 用 来 持久 化 数据 的 ， 或 者 进行 文件 共享 的 。 未 来 版 本 可 能 会 对 
这 部 分 进行 重 构 ， 将 信息 数据 卷 提 供 的 功能 放 在 更 合适 的 地 方 。 


7.5.1 Secret 


Kubernetes 提 供 了 Secret 来 处 理 敏 感 数据 ， 比 如 密码 、Token 和 密 
钥 ， 相 比 于 直接 将 敏感 数据 配置 在 Pod 的 定义 或 者 镜像 中 ，Secret 提 供 
了 更 加 安全 的 机 制 ， 防 止 数据 泄露 。 


Secret 的 创建 是 独立 于 Pod 的 ， 以 数据 卷 的 形式 挂 载 到 Pod 中 , 
Secret 的 数据 将 以 文件 的 形式 保存 ， 容 器 通过 读 取 文件 可 以 获取 需要 的 
数据 。 


Secret 的 类 型 有 3 种 。 
e Opaque: 目 定 义 数 据 内 容 ， 默认 值 。 


e kubernetes.io/service-account-token: Service Account 的 认证 内 容 ， 
可 参考 10.3 节 。 


* kubernetes.io/dockercfg: Docker 镜 像 仓库 的 认证 内 容 ， 可 参考 
4.3.1 节 。 


现在 有 一 个 应 用 需要 获取 一 个 账号 密码 ， 即 可 以 通过 Secret 来 实 
E. 


username: my-username 


password: my-password 


因为 是 自 定 义 数 据 内 容 ， 所 以 Secret 的 类 型 是 Opaque， 配 置 的 数据 
是 一 系列 Key/Value 对 ， 其 中 Value 需要 使 用 Base64 加 密 ，Secret 定 义 文 
件 secret.yaml: 


apiVersion: v1 
kind: Secret 
metadata: 
name: mysecret 
type: Opaque 
data: 
username: bXktdXNlcm5hbWUK 


password: bXktcGFzc3dvcmQK 


通过 定义 文件 创建 Secret: 


$ kubectl create -f secret.yaml 


secret "mysecret" created 


创建 成 功 后 查询 Secret: 


$ kubectl describe secret mysecret 


Name: mysecret 
Namespace: default 
Labels: <none> 
Annotations: «none» 


Type: Opaque 


password: 12 bytes 


username: 12 bytes 


然后 创建 Pod 使 用 该 Secret， 


apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 

labels: 

app: busybox 

spec: 

containers: 


- name: busybox 


Pod 的 定义 文件 : 


image: busybox 

command: 

- sleep 

- "3600" 

volumeMounts: 

- mountPath: /secret 
name: secret 
readOnly: true 

volumes: 
- name: secret 
secret: 


secretName: mysecret 


Pod 的 定义 中 声明 了 Secret 数 据 卷 ， 并 且 将 Secret 数 据 卷 挂 载 到 了 
Pod E28 FAY /secret HK F, KK Sece Pj Key/ValueX], dE 
的 /secret 目 了 永 中 分 别 有 两 个 文件 username 和 password， 文 件 的 内 容 束 是 
解密 后 的 数据 : 


$ kubectl exec busybox -- ls /secret 

password 

username 

$ kubectl exec busybox -- cat /secret/username 


my-username 


$ kubectl exec busybox -- cat /secret/password 


my - password 


7.5.2 Downward API 


Downward API 可 以 通过 环境 变量 的 方式 告诉 容器 Pod 的 信息 (可 参 
考 4.3.3 节 ) ， 另 外 ， 也 可 以 通过 数据 卷 方式 传 值 ，Pod 的 信息 将 会 以 文 
件 的 形式 通过 数据 卷 挂 载 到 容 髓 中 ， 在 容 融 中 可 以 通过 读 取 文 件 获取 
信息 ， 目 前 文 持 ; 


。Pod 的 名 称 。 
。Pod 的 Namespace ° 
。Pod 的 Label。 
。Pod 的 Annotation ° 


创建 Pod 使 用 Downward API 数 据 卷 ，Pod 的 定义 文件 downwardapi- 


volume.yaml: 


apiVersion: vi 
kind: Pod 
metadata: 
name: downwardapi-volume 
labels: 
zone: us-est-coast 
cluster: test-cluster1 
rack: rack-22 
annotations: 


build: two 


builder: john-doe 


spec: 
containers: 
- name: client-container 
image: ubuntu:14.04 

command: ["/bin/bash",  "-c", 

done"] 
volumeMounts: 

- name: podinfo 
mountPath: /podinfo/ 
readOnly: false 

volumes: 


- name: podinfo 
downwardAPI: 
items: 
- path: "pod name" 


fieldRef: 


fieldPath: metadata.name 


- path: "pod namespace" 


fieldRef: 


"while true; 


fieldPath: metadata.namespace 


- path: "pod labels" 
fieldRef: 


fieldPath: metadata.labels 


- path: "pod annotations" 


fieldRef: 


fieldPath: metadata.annotations 


do sleep 5; 


Pod 定 义 中 声明 了 Downward API 数 据 卷 ， 分 别 引 用 了 Pod 的 相关 局 
性 ， 然 后 将 数据 卷 挂 载 到 容器 /podinfo 目 未 下 。 在 Pod 创 建 运行 后 ， 就 
可 以 查询 /podinfo 目 录 下 的 数据 : 


$ kubectl exec downwardapi-volume -- ls /podinfo 
pod annotations 

pod labels 

pod name 


pod namespace 


$ kubectl exec downwardapi-volume -- cat /podinfo/pod name 


downwardapi-volume 


$ kubectl exec downwardapi-volume -- cat /podinfo/pod namespace 
default 
$ kubectl exec downwardapi-volume -- cat /podinfo/pod labels 


clusterz"test-clusteri" 


rack="rack-22" 


$ kubect1 exec downwardapi-volume -- cat 
/podinfo/pod annotations 

build-"two" 

builder="john-doe" 
kubectl.kubernetes.io/last-applied-configurationz"..." 
kubernetes.i0/config.seen="2015-11-02T18:29:57.509960318+08:00" 


kubernetes.io/config.source="api" 


7.5.3 Git Repo 


Kubernetes X Ef Git = 2 P2€«s|Pod"", H Av ei Git Repo 数 据 
卷 实 现 ， 即 当 Pod 配 置 Git Repo 数 据 卷 和 时， 或 下 载 配 置 的 Git 仔 库 到 Pod 
的 数据 卷 中 ， 然 后 挂 载 到 容器 中 。 我 们 现在 定义 一 个 Pod 使 用 Git Repo 
数据 卷 ，Pod 的 定义 文件 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: busybox 
labels: 
app: busybox 
spec: 
containers: 
- name: busybox 
image: busybox 
command: 
- sleep 
- "3600" 
volumeMounts: 
- mountPath: /config 
name: busybox-config 
volumes: 
- name: busybox-config 
gitRepo: 
repository:  https://github.com/wulonghui/busybox- 


config.git 


revision: master 


Pod 的 定义 中 声明 了 Git Repo 数 据 卷 ， 然 后 挂 载 到 容 絮 的/config 目 
录 下 ， 在 Pod 运 行 后 ， 即 会 下 载 指 定 的 Git 仓 库 到 /config 目 录 下 : 


$ kubectl exec busybox -- ls /config 


busybox-config 


第 8 章 
访问 Kubernetes API 


Kubernetes 规 范 和 健全 的 API 模 型 ， 为 Kubernetes 的 使 用 和 扩展 提 
供 了 非常 好 的 文 持 。 


本 章 首 先 说 明 Kubernetes 提 供 的 API 对 象 以 及 元 数据 ， 然 后 介绍 
Kubernetes API 的 访问 方式 ， 最 后 详细 阐述 Kubemetes 的 命令 行 工 具 ， 
帮助 读者 真正 掌握 如 何 使 用 Kubernetes 。 


8.1 API RSA 


Kubernetes 中 的 很 多 功能 是 通过 API 对 象 来 实现 的 ， 在 前 面 的 章 
中 我 们 已 经 创建 过 许多 API 对 象 ， 包 括 Pod ` Replication Controller ^ 
Service 和 Secret 等 。 在 定义 API 对 象 的 时 候 需 要 分 别 声 明 API 版 本 
(apiVersion) 和 类 型 (kind) ， 当 前 版 本 Kubernetes v1.1.1 支 持 的 API 
对 象 的 API 版 本 和 类 型 如 下 所 示 : 


。V1/Pod 
e vi/ReplicationController 
e v]/Service 


e v1/Endpoints 


e v1/Events 

e vi/Node 

e v1/Namespace 

e v]/Secret 

e v1/ServiceAccount 

e v]/Persistent Volume 

e vi/PersistentVolumeClaim 

e v1/LimitRange 

e v1/ResourceQuota 

* extensions/v1beta1/Deployment 
e extensions/v1beta1/HorizontalPodAutoscaler 
e extensions/v1beta1/Ingress 

e extensions/v1beta1/Job 


* extensions/v1beta1/Daemonset 


API 对 象 的 元 数据 用 来 定义 API 对 象 的 基本 信息 ， 体 现在 定义 中 的 
metadata 字 段 ， 包 含 以 下 属性 。 


e namespace: 指定 API 对 象 所 在 的 Namespace 。 


ename: 指定 API 对 象 的 名 称 。 

e labels: 设置 API 对 象 的 Label ° 

e annotations: 设置 API 对 象 的 Annotation ° 
Namespace 


Namespace 是 Kubernetes 提 供 的 多 租户 ， 不 同 的 项 目 、 团 队 或 者 用 
户 可 以 通过 Namespace 进 行 区 分 管理 ， 并 有 旦 设置 安全 控制 和 其 他 宽 
略 。 绝 大 部 分 API 对 象 (除了 Node) 归属 于 Namespace，API 对 象 通 
过 .metadata.namespace 指 定 Namespace ， 如 果 没 有 指定 Namespace， 那 
么 就 是 归属 于 默认 Namespace default ° 


Name 


名 称 是 一 个 重要 的 属性 ， 是 人 类 可 读 的 ， 元 数据 中 
的 .metadata.name 用 于 指定 API 对 象 的 名 称 。Kubernetes 系 统 中 的 API 对 
象 必须 能 够 通过 名 称 唯 一 标识 ，Kubernetes 包 含 Namespace 的 逻辑 层 
级 ， 大 部 分 API 对 象 必须 归属 于 Namespace， 所 以 这 些 API 对 象 的 名 称 
必须 在 Namespace 内 唯一 。 而 另外 对 于 Node 和 Namespace 来 说 ， 需 要 在 
Kubernetes 系 统 中 唯一 。 


Label 


Label 用 于 区 分 API 对 象 的 Key/Value 对 ，Label 存 放 的 应 该 是 具有 标 
识 性 的 数据 ，Kubemnetes 通 过 Label 可 以 对 API 对 象 进行 选择 。 
Replication Controller 和 Service 都 是 通过 Label 关 联 Pod， 而 Pod 也 可 以 通 
i Labelitt}#Node ° 


Annotation 


Annotation 用 于 存放 用 户 的 和 目 定 义 数 据 ，Annotation 存 放 的 是 非 标 
识 的 数据 ， 所 以 不 能 像 Label 一 样 进行 对 象 选 择 。 但 是 Annotation 的 数 
据 可 以 是 长 数据 ， 可 以 有 结构 或 者 无 结构 ， 作 为 Label 的 一 种 补充 ， 
Annotation 也 是 Key/Value 对 : 


annotations: 
key1: value1i 


key2: value2 


8.2 ”如 何 访问 Kubernetes API 


使 用 Kubernetes 都 需要 访问 其 API， 而 Kubernetes API Server 作 为 
Kubernetes 系 统 的 入 口 ， 以 REST API 接 口 方式 提供 给 外 部 调用 ， 上 所 以 
访问 Kubernetes API Sz b E Wi xe Val H Kubernetes API Server。 其 中 
Kubernetes API Server 集 成 了 Swagger， 可 以 通过 界面 查询 所 有 API 的 详 
细 信 息 (http://kube-master:8080/swagger-ui/) ， 如 图 8-1 所 示 。 


) swagger Iipiimube-masters0s0'swagger-ui././swaggerspe) oy TM 


api: get available API versions 

apis : get available API versions 
extensions : get information of a group 
v1 : API at /api/v1 


v1beta1 : API at /apis/extensions/v1beta1 


version : git code version from which this is built 


€ swagger LS CT MM 


Kj8-1 Kubernetes 集 成 Swagger 提 供 API 查 询 


除 此 之 外 ， 社 区 中 封闭 提供 了 各 种 开发 语言 的 Kubernetes 客 户 端 
Lib 包 ， 如 图 8-1 所 示 ， 可 以 使 用 这 些 Lib 包 来 开发 程序 以 访问 


Kubernetes API ° 


328-1 Kubernetes 客 户 端 Lib 包 


Kubernetes Client 


https://github.com/kubernetes/kubernetes/tree/v1.1.1/pkg/client 


Amdatu Kubernetes 


https://bitbucket.org/amdatulabs/amdatu-kubernetes 


kubernetes-client 


kubeclient 


https://github.com/fabric8io/kubernetes-client 
https://github.com/Ch00k/kubr 
https://github.com/abonas/kubeclient 


kubernetes-client 


https://github.com/maclof/kubernetes-client 


kubernetes-api-php-client 


node-kubernetes-client 


https://github.com/devstub/kubernetes-api-php-client 


https://github.com/tenxcloud/node-kubernetes-client 


Net::Kubernetes 


https://github.com/kubernetes/kubernetes/blob/v1 .1.1/docs/devel/ 


client-libraries.md 


8.3 ”使 用 命令 行 工具 kubectl 


Kubernetes 提 供 了 命令 行 工 具 kubectl， 它 提供 了 非常 简洁 快速 的 方 
法 来 访问 Kubernetes API， 可 以 满足 大 部 分 对 Kubernetes 的 操作 。 
kubectl 可 以 从 Kubermnetes 发 布 包 中 获取 ， 其 中 platforms 目 录 下 放置 着 各 
个 平台 的 kubectl 可 执行 文件 : 


$ wget 
https://github.com/kubernetes/kubernetes/releases/download/v1i.1 
.1/kubernetes.tar.gz 

$ tar zxvf kubernetes.tar.gz 


$ cd kubernetes/platforms 


命令 行 工具 kubectl 包 含 的 命令 如 表 8-2 所 示 。 


表 8-2 ”kubectl 命 令 


pe 说 明 
kubectl config 操作 Kubeconfig 文 件 
kubectl version 查询 Kubernetes 版 本 信息 
kubectl api-versions 查询 Kubernetes 支 持 的 API 版 本 信息 
kubectl cluster-info 查询 Kubernetes 运 行 环境 信息 
kubectl proxy 为 Kubernetes API Server 启 动 服务 代理 
kubectl create 创建 API 对 象 
kubectl delete 删除 API 对 象 
kubectl edit 编辑 API 对 象 
kubectl apply 更 新 API 对 象 
kubectl patch 为 API 对 象 打 补 丁 
kubectl label 操作 API 对 象 的 Label 
kubectl annotate 操作 API 对 象 的 Annotation 
kubectl logs 获取 Pod 中 容器 的 输出 日 志 
kubectl autoscale 执行 Pod 的 自动 伸缩 
kubectl rolling-update 执行 Pod 的 滚动 升级 
kubectl scale 执行 Pod 的 弹性 伸缩 
kubectl attach 连接 Pod 中 启动 的 容器 
kubectl exec 在 Pod 的 容器 中 执行 命令 
kubectl port-forward 为 Pod 设 置 端口 转发 


kubectl run Gi ££& Replication Controller 


kubectl expose 创建 Service 


8.3.1 配置 Kubeconfig 


使 用 kubectl 命 令 行 的 时 候 首 先 需 要 配置 Kubeconfig 文 件 ， 用 于 配 
置 如 何 访问 Kubernetes API， 包 括 Kubernetes API Server 的 URL 和 认证 
言 恩 等 ， 并 且 可 以 设置 不 同 的 上 下 文 环境 ， 快 速 切换 访问 环境 © 


下 面 是 一 个 Kubeconfig 文 件 示例 : 


apiVersion: v1 
kind: Config 
clusters: 
- cluster: 
certificate-authority: /etc/kubernetes/ca/ca.crt 
server: https://kube-master : 6443 
name: k8s 
users: 
- name: k8s-client 
user: 
client-certificate: /etc/kubernetes/ca/client.crt 
client-key: /etc/kubernetes/ca/client.key.insecure 
- name: k8s-admin 
user: 
password: test 
username: k8s-admin 
contexts: 
- context: 


cluster: k8s 


user: k8s-admin 
namespace: default 
name: default 
current-context: default 


preferences: {} 
Kubeconfig 文 件 的 定义 中 包含 以 下 关键 部 分 。 
e clusters: 设置 Kubernetes API Server 的 访问 URL 和 相关 属性 。 
e users: 设置 访问 Kubernetes API Server 的 认证 信息 。 
。contexts: 设置 kubelet 执 行 上 下 文 。 
* current-context: 设置 kubelet 执 行当 前 上 下 文 。 
* preferences: 设置 kubelet 其 他 属性 。 


Kubeconfig 文 件 可 以 手动 进行 编辑 ， 也 可 以 通过 kubectl config 命 令 
进行 得 询 和 设置 ， 如 表 8-3 所 示 。 
%28-3 kubectl config 命 令 
命令 说 明 


kubectl config view 查看 Kubeconfig 文 件 
kubectl config set-cluster 设置 Kubeconfig 的 clusters 


kubectl config set-credentials 设置 Kubeconfig 的 users 


kubectl config set-context 设置 Kubeconfig 的 contexts 


kubectl config use-context 设置 Kubeconfig 的 current-context 


8.3.2”Kubernetes 操 作 


kubectl version 


kubectl version 命令 用 来 查询 Kubernetes 的 版 本 信息 ， 包 括 客 户 端 
和 服务 端 ， 这 在 问题 定位 的 时 候 特 别 有 帮 助 : 


$ kubectl version 
Client Version: 


version. Info{Major:"1",Minor:"1",GitVersion:"v1.1.1",GitCommit: 


" " 
n.a I 


GitTreeState:"clean"} 
Server Version: 


version. Info{Major:"1",Minor:"1",GitVersion:"v1.1.1",GitCommit: 


" " 
n.a I 


GitTreeState:"clean"} 


kubectl api-versions 


kubectl api-versions 命 令 可 以 查询 Kubernetes 文 持 的 API 版 本 : 


$ kubectl api-versions 
extensions/vibetat 


vi 


kubectl cluster-info 


kubectl cluster-info 命 令 可 以 查询 Kubernetes 的 运行 环境 信息 ， 包 括 
Kubernetes API Server 和 平台 级 别 Service ( kubernetes.io/cluster- 
service=true) 的 地 址 : 


$ kubectl cluster-info 

Kubernetes master is running at http://k8s-master : 8080 

KubeDNS is running at http://k8s- 
master :8080/api/v1/proxy/namespaces/kube-system/services/ 
kube-dns 

KubeUI is running at http://k8s- 
master :8080/api/v1/proxy/namespaces/kube-system/services/ 


kube-ui 


kubectl proxy 


kubectl proxy f & n] LAX Kubernetes API Server 在 本 地 启动 一 个 代 
理 服务 ， 访 问 这 个 代理 服务 就 可 以 访问 Kubernetes API Server ° 


执行 kubect proxy 的 时 候 可 以 指定 监听 端口 和 API 访 问 前 级 : 


$ kubectl proxy --port=8011 --api-prefix-/k8s-api 


Starting to serve on 127.0.0.1:8011 


kubectl proxy 启 动 后 就 可 以 通过 http://127.0.0.1:8011/k8s-api 访 问 到 
代理 服务 ， 从 而 访问 Kubernetes API Server ° 


8.330 API REE 


kubecd 命 令 行 可 以 操作 API 对 象 ， 执 行 的 时 候 需 要 指定 API 对 象 的 
类 型 ， 类 型 可 以 用 单数 形式 、 复 数 形式 或 者 简写 形式 ， 具 体 如 下 所 


ZN: 


e pod/pods/po 

e replicationcontroller/replicationcontrollers/rc 
e daemonset/daemonsets/ds 

e service/services/svc 

e endpoints/ep 

e event/events/ev 

e node/nodes/no 

e namespace/namespaces/ns 

* secret/secrets 

* serviceaccount/serviceaccounts 

e persistentvolume/persistentvolumes/pv 

* persistentvolumeclaim/persistentvolumeclaims/pvc 
* limitrange/limitranges/limits 

* resourcequota/resourcequotas/quota 

* componentstatuses/cs 


* daemonset/daemonsets/ds 


* deployment/deployments 

* horizontalpodautoscaler/horizontalpodautoscalers/hpa 
* ingress/ingresses/ing 

e job/jobs 

kubectl create 


kubectl create 命 令 用 来 创建 API 对 象 ， 格 式 文 持 JSON 和 YAML ° fE 
用 kubectl create 主 要 是 通过 定义 文件 进行 创建 : 


$ kubectl create -f /path/to/file 
也 可 通过 传递 标准 输入 (stdin) 进行 创建 : 
$ cat /path/to/file | kubectl create -f - 


kubectl create 支 持 连 续 创 建 多 个 API 对 象 : 


$ kubectl create -f /path/to/file1 -f /path/to/file2 


kubectl get 


kubectl get 命 令 可 以 用 来 查询 各 类 API 对 象 的 信息 。 


kubectl get 可 以 查询 指定 API 对 象 : 


$ kubectl get TYPE NAME 


可 以 查询 一 个 类 型 的 所 有 API 对 象 : 


$ kubectl get TYPE 
也 可 以 同时 查询 多 个 类 型 ， 类 型 之 间 用 ,分 隔 : 
$ kubectl get TYPE1, TYPE2 


kubectl get x: 43833 Label ffit APII] 25 : 


$ kubectl get TYPE --selector key1=value1, key2=value 


默认 情况 下 ，kubectl get 只 会 显示 人 简要 信息 ， 以 下 方式 可 以 显示 详 
Zl a: 


$ kubectl get TYPE NAME --output json 


$ kubectl get TYPE NAME --output yaml 


kubectl get 也 支持 通过 Go Template 或 者 JSON Path 提 取 指 定 信 息 : 


$ kubectl get TYPE NAME --output go-template=... 


$ kubectl get TYPE NAME --output jsonpath-... 


kubectl describe 


kubectl describe 命 令 可 以 用 来 查询 各 类 API 对 和 象 的 概况 信息 ， 支 持 
批量 查询 和 指定 查询 : 


$ kubectl describe TYPE 


$ kubectl describe TYPE NAME 


kubectl delete 


kubectl delete 命 令 用 来 删除 API 对 象 ， 删 除 的 时 候 可 以 指定 API 对 
象 进行 删除 : 


$ kubectl delete TYPE NAME 
也 可 以 通过 定义 文件 删除 : 
$ kubectl delete -f /path/to/file 


另外 ，kubectl delete 命 令 可 以 进行 批量 删除 ， 多 个 API 对 象 类 型 之 
间 用 ,分 隔 : 


$ kubectl delete TYPE1,TYPE2 --all 
BY x Hw Labelfr326 HR: 
$ kubectl delete TYPE1,TYPE2 --selector key1=valuei1, key2=value 


kubectl apply 


kubectl apply ti 4& n] LJ Fd 2 Gr CE OEM APDTR, EB ee 
义 文件 进行 修改 : 


$ kubectl apply -f /path/to/file 
也 可 通过 传递 标准 输入 (stdin) 进行 修改 : 
$ cat /path/to/file | kubectl apply -f - 


kubectl replace 


kubectl replace 命 令 与 kubectl apply 类 似 ， 都 可 以 用 来 更 新 已 创建 的 
API 对 象 : 


$ kubectl apply -f /path/to/file 


但 有 时 候 API 对 象 的 有 些 属 性 无 法 直接 更 新 ， 这 时 候 可 以 使 用 
kubectl replace 命 令 强 制 进行 重建 以 实现 更 新 ; 


$ kubectl apply -f /path/to/file --force 
kubectl edit 


kubectl edit 命 令 可 以 用 来 编辑 已 创建 的 API 对 象 ， 使 用 kubectl edit 
命令 的 时 候 会 开启 一 个 编辑 器 。 通 过 编辑 器 可 以 方便 地 对 API 对 象 进 
行 编辑 ， 默 认 的 编辑 俐 是 VI， 可 以 通过 环境 变量 KUBE_EDITOR 选 择 
其 他 编辑 器 : 


$ KUBE EDITOR-"nao" kubectl edit TYPE NAME 

在 编辑 器 中 默认 显示 的 格式 是 YAML， 也 可 以 指定 为 JSON: 
$ kubectl edit TYPE NAME --output json 

kubectl patch 


kubectl patch 命 令 可 以 给 API 对 象 打 补丁 ， 即 修改 指定 属性 ， 这 样 
可 以 非常 方便 地 修改 API 对 象 ， 其 中 PATCH 有 要 使 用 JSON 格 式 : 


$ kubectl patch TYPE --patch PATCH 


kubectl label 


kubectl label 命 令 可 以 用 来 操作 API 对 象 的 Label， 包 括 增加 、 修 改 
和 删除 。 


给 API 对 象 增 加 Label， 多 个 Label 之 间 用 空格 分 隔 ; 
$ kubectl label TYPE NAME labeli=value1 label2-value2 

更 新 API 对 象 已 有 的 Label， 需 要 加 上 --overwrite 参 数 进行 禾 盖 ; 
$ kubectl label TYPE NAME labeli=new-value --overwrite 


删除 API 对 象 已 有 的 Label， 在 Label 的 KEY 后 面 加 上 -: 


$ kubectl label TYPE NAME label1- 


另外 ，kubectl label th, 3z 5:38 33 BS BV --all Fl --selector f (7 115 Œ PR 
VE o 


kubectl annotate 


kubectl annotate 命 令 可 以 用 来 操作 API 对 象 的 Annotation kubectl 
annotate |E] kubectl label 命令 差不多 ， 只 不 过 操作 的 对 象 换 成 


Annotation ° 


给 API 对 象 增 加 Annotation: 


$ kubect1 annotate TYPE NAME annotationi-value1 


annotation2-value2 


更 新 API 对 象 已 有 的 Annotation， 需 要 加 上 --overwrite 参 数 进 行 履 


ES 
TL: 


$ kubectl annotate TYPE NAME annotationi=new-value --overwrite 


WUERAPDG & EA Hy Annotation, 7£AnnotationhKEY Ja Ifi JJII. E--: 


$ kubectl annotate TYPE NAME annotationi- 


8.3.4 Pod 操 作 


kubectl logs 


kubectl logs 命 令 用 于 打印 Pod 中 容器 的 日 志 输 出， 如 果 Pod 只 有 一 


as, WN ie SETAE AA: 
$ kubectl logs mypod 
而 当 Pod 有 多 个 容器 的 时 候 ， 需 要 指定 容器 : 


$ kubectl logs mypod container 


kubectl loge un 打印 所 有 日 志 ，--limit-bytes 参 数 可 以 限定 日 志 
打印 量 ， 而 通过 --tail 参 数 可 以 只 打印 最 新 的 指定 行 数 的 日 志 ， 或 者 通 
过 --since 和 --since-time 打 印 指定 时 间 的 日 志 。 另 外 ， 通 过 设置 --follow 
参数 ， 将 实时 打印 日 志 流 ， 达 到 tail -{ 的 效果 。 


kubectl attach 


kubectl attach 命令 用 于 连接 到 Pod 中 局 动 的 容器 ， 类 似 于 docker 
attach， 如 果 不 指 定 容 器， 则 选择 Pod 的 第 一 个 容 妖 : 


$ kubectl attach mypod 
tH AY DATS RAR: 
$ kubectl attch mypod container 


kubectl exec 


kubectl exec 命 令 用 于 在 Pod 的 容器 中 执行 命令 ， 类 似 于 docker 
exec， 如 果 不 指定 容器 ， 则 选择 Pod 的 第 一 个 容 絮 : 


$ kubectl exec mypod -- date 


当然 可 以 指定 容器 执行 : 


$ kubectl exec mypod container -- date 


提示 


kubectl exec 命 令 需 要 在 Kubernetes Node 上 安装 nsenter ° 


kubectl port-forward 


kubectl port-forward ft Senn) 以 为 Pod 设 置 端口 转发 ， 通 过 在 本 机 监 
听 指 定 端口 ， 访 问 这 些 端口 的 请 求 将 b d. 中 对 应 的 
端口 上 。 


TA fT kubectl portrforward 命 令 的 时 候 需 要 指定 Pod 和 端口 转发 规 
则 ， 比 如 80 端 口 转发 80 端 口 ，443 端 口 转发 443 端 口 : 


$ kubectl port-forward mypod 80:80 443:443 


提示 


kubectl port-forward 命 令 需 要 在 Kubernetes Node 上 安装 nsenter 和 


socat ° 


8.3.5 Replication Controller 操 作 


kubectl run 


kubectl run 命 令 可 以 用 来 创建 Replication Controller， 创 建 的 时 候 必 
须 指定 容器 镜像 : 


$ kubectl run nginx --image nginx 


创建 的 Replication Controller 的 Pod 副 本 数 是 1， 可 以 通过 --replicas 
参数 设置 Pod 的 副本 数 为 2: 


$ kubectl run nginx --image nginx --replicas 2 


默认 情况 下 ， 创 建 出 来 的 Replication Controller: X Podix E — “+ 
Label，Label 的 Key 为 rn，Value 为 Replication Controller) 4 Fk ° UFR 


kubectl run 命 令 中 设置 了 --labels 参 数 ， 则 会 覆盖 这 个 Label。 


kubect run 命 令 中 只 可 以 设置 一 个 容器 ， 支 持 容 器 的 属性 设置 如 下 
所 示 。 


。--command: 容器 的 启动 命令 。 


e --hostport: 容器 映 冉 到 答 主 机 的 端口 。 
*--env: 容器 的 环境 变量 。 

e --requests: 容器 的 资源 请 求 规格 。 

e limits: 容器 的 资源 限制 规格 。 


kubectl scale 


kubectl scale A & FJ LA H Æ f£ PX Replication Controller 4‘) Pod & AS 
数 ， 即 实现 Pod 的 弹性 伸缩 。 执 行 的 时 候 需 要 指定 Replication Controller 
和 Pod 副 本 数 : 


$ kubectl scale replicationcontroller nginx --replicas-3 


kubectl scale 命 令 如 果 设 置 了 --current-replicas 参 数 ， 那 么 会 验证 当 
前 Pod 的 副本 数 是 否 等 于 --current-replicas 配 置 的 数目 ， 相 等 才 进 行 修改 
TRE 。 


kubectl autoscale 


kubectl autoscale ft? € FJ DJ 7j Replication Controller &/| Horizontal 
Pod Autoscaler, ， 即 实现 Pod 的 目 动 伸缩 。 执 行 的 时 候 需 要 指定 
Replication Controller， 以 及 Pod 的 最 大 和 最 小 副本 数 : 


$ kubectl autoscale replicationcontroller nginx --min=1 -- 


max=10 


8.3.6 ”Service 操 作 


kubectl expose 


kubectl expose 命 令 可 以 用 来 创建 Service， 创 建 的 时 候 需 要 指定 
Pod ` Replication Controller 或 者 Service， 从 中 提取 Label 来 为 新 建 的 
Service 配 置 Label Selector: 


$ kubectl expose pod valid-pod --port=444 --name=frontend 

$ kubectl expose replicationcontroller nginx  --port-80 -- 
target -port-8000 

$ kubectl expose service nginx --port=443 --target-port=8443 -- 


name=nginx -https 
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第 12 章 ”管理 和 运 维 Kubernetes 


第 9 章 
Kubernetes 网 络 


Kubermnetes 从 Docker 默 认 的 网 络 模型 中 独立 出 来 形成 一 套 目 己 的 网 
络 模型 ， 该 网 络 模型 更 加 适应 传统 的 网 络 模式 ， 应 用 能 够 平滑 地 从 非 
容 絮 环境 迁移 到 同 Kubernetes 中 。 本 划 将 对 比 说 明 Kubernetes 和 Docker 
的 网 络 模型 ， 然 后 详细 讲解 Kubernetes 网 络 模型 的 实现 细节 e 


9.1 Docker HRA 


Docker {i Hj Linux f/f #2, 4E fa = WL E E $4. A Docker W f 
(docker0) ，Docker 启 动 一 个 容器 时 会 根据 Docker 网 桥 的 网 段 分 配 容 
需 的 卫 ， 同 时 Docker 网 桥 是 每 个 容 需 的 默认 网 关 。 因 为 在 同一 宿主 机 
内 的 容器 都 接 入 同一 个 网 桥 ， 这 样 容器 之 间 束 能 通过 容 右 的 IP 直 接 通 
信 ， 如 图 9-1 所 示 。 


etho 
Host 


dockero 
172:17:42:1/24 


图 9-1 Docker 网 络 


Docker 网 桥 是 答 主 机 虚拟 出 来 的 ， 并 不 是 真实 存在 的 网 络 设备 ， 
外 部 网 络 是 无 法 寻 址 到 的 ， 这 也 意味 着 外 部 网 络 无 法 直接 访问 到 容 
器 。 如 果 容 器 希望 能 够 被 外 部 网 络 访问 到 ， 就 需要 通过 映射 容器 端口 
到 宿主 机 (端口 映射 )， 即 使 用 docker run 创 建 容器 时 通过 -p 或 -P 参 数 
来 启用 ， 访 问 容 器 的 时 候 通 过 [宿主 机 了 了 ]:[ 容 器 端口 ] 访 问 容 句 。 


实际 上 ， 端 口 映 射 通 过 在 iptables 的 NAT 表 中 添加 相应 的 规则 ， 所 
以 我 们 也 将 端口 映射 方式 称 为 NAT 方 式 。 在 早期 组 建 Docker 机 器 集群 
的 方案 中 ， 往 往 是 选择 了 NAT 方 式 的 网 络 模型 。 这 种 网 络 模型 对 使 用 
的 便利 性 是 有 意义 的 ， 但 并 不 理想 。 这 个 模型 需要 对 各 种 端口 进行 映 
射 ， 这 会 限制 箱 主 机 的 能 力 ， 在 容 需 编排 上 也 增加 了 复杂 度 。 


-HO cae ERRAT. TR EROR O RAMS ic sina L1 [9] 
题 。 这 不 但 使 调度 复杂 化 ， 而 且 应 用 程序 的 配置 也 将 变 得 复 淋 ， 具 体 
表现 为 端口 冲突 、 重 用 和 耗 尽 。 


e NAT 将 地 址 空间 分 段 的 做 法 引入 了 额外 的 复杂 度 。 比 如 容 右 中 
应 用 所 见 的 卫 并 不 是 对 外 暴露 的 卫 ， 因 为 网 络 隔离 ， 容 器 中 的 应 用 实 
际 上 只 能 检测 到 容器 的 IP， 但 是 需要 对 外 宣称 的 则 古 答 主机 的 他 ， 这 
种 信息 的 不 对 称 将 市 来 诸如 破坏 目 注 册 机 制 等 问题 。 


9.2 ”Kubernetes 网 络 模型 


Kubernetes 从 Docker 网 络 模型 (NAT 方 式 的 网 络 模型 ) 中 独立 出 来 
形成 一 套 新 的 网 络 模型 。 该 网 络 模型 的 目标 是 : 每 一 个 Pod 都 拥有 一 
个 局 平 化 共享 网 络 命名 空间 的 IP， 称 为 PodIP。 通 过 PodIP，Pod 能 够 跨 
网 络 与 其 他 物理 机 和 Pod 进 行 通 信 。 一 个 Pod 一 个 IP 的 (IP-Per-Pod) 模 
型 创建 了 一 个 干净 、 反 问 兼 容 的 模型 。 在 该 模型 中 ， 从 端口 分 配 、 网 
络 、 域 名 解析 、 服 务 发 现 、 负 载 均 衡 、 应 用 配置 和 迁移 等 角度 ，Pod 
都 能 够 被 看 成 虚拟 机 或 物理 机 ， 这 样 应 用 残 能 够 平滑 地 从 非 容 赂 环境 

(物理 机 或 虚拟 机 ) 迁移 到 同一 个 Pod 内 的 容器 环境 。 


为 了 实现 这 个 网 络 模型 ， 在 Kubernetes 中 需要 解决 几 个 问题 ; 
。 容 器 间 通 信 (Container to Container) 
。Pod 间 通信 (Pod to Pod) 


。Service 到 Pod 的 通信 (Service to Pod) 


9.3 ”容器 间 通 信 


Pod 是 容器 的 集合 ，Pod 包 含 的 容器 都 运行 在 同一 个 答 主 机 上 ， 这 
些 容 紫 将 拥有 同样 的 网 络 空 间 ， 容 器 之 间 能 够 互相 通信 ， 它 们 能 够 在 
本 地 访问 其 他 容器 的 端口 。 


现在 创建 一 个 Web Pod, BEM has: A aswebpod804} fa 5/] ki 
听 80 端 口 的 Web 服 务 ， 容 器 webpod8080 将 启动 监听 8080 端 口 的 Web 服 
务 ， 同 时 配置 了 端口 映射 规则 。Web Pod 的 定义 文件 web-pod.yaml: 


apiVersion: v1 
kind: Pod 
metadata: 
name: webpod 
labels: 
name: webpod 
spec: 
containers: 
- name: webpod80 
image: jonlangemak/docker:web container 80 
ports: 
- containerPort: 80 
hostPort: 80 
- name: webpod8080 
image: jonlangemak/docker:web container 8080 


ports: 


- containerPort: 8080 


hostPort: 8080 


Web Podi, TEXLPITERJNode E Bia) Aan: 


$ docker ps 

CONTAINER ID IMAGE PORTS 
63dc7e032ab6  jonlangemak/docker:web container 8080 
4acia5156a04  jonlangemak/docker:web container 80 

b77896498f8f gcr.io/google containers/pause:0.8.0 
0.0.0.0:80->80/tcp,0.0.0.0:8080->8080/tcp 


可 以 看 到 运行 了 3 个 容 右 ， 其 中 前 两 个 容器 钙 在 Web Pod 定 义 中 指 
ER, nf DL BR 7S dy 5$ A ao 370m f y BHR E 
gcr.io/google containers/pause:0.8.0, Web Pod 定 义 中 设置 的 业务 容器 的 
端口 映射 规则 都 集中 配置 在 了 网 络 容器 上 ， 实 际 上 它 是 Kubernetes 中 
定义 的 网 络 容 器 ， 它 不 做 任何 事情 ， 只 是 用 来 接管 Pod 的 网 络 ， 业 务 
容 磊 通过 加 入 网 络 容 强 的 网 络 实现 网 络 共 至 。 


那么 为 什么 要 使 用 额外 的 网 络 容器 ， 而 不 是 以 Pod 的 第 一 个 容 右 
作为 网 络 容 絮 呢 ? 主 要 十 为 了 避免 业务 容器 之 间 产 生 依 赖 ， 比 如 第 二 
个 容 紫 连接 到 第 一 个 容器 ， 当 第 一 个 容器 宕 机 时 ， 那 么 第 二 个 容 吕 的 
网 络 栈 也 会 失效 。 


网 络 容 絮 锐 像 可 以 通过 Kubelet 的 启动 参数 --pod-infra-container- 
image 指定 ， 不 同 版 本 下 使 用 的 默认 镜像 不 一 样 ， 当 前 版 本 


(Kubernetes v1.1.1) 默认 是 gcr.io/google_containers/ pause:0.8.0， 这 是 


一 个 非常 小 的 镜像 ， 局 动容 器 后 只 会 运行 一 个 叫 作 pause 的 程序 ， 顾 名 
思 义 ，pause 的 作用 只 十 暂 停 ， 防 止 容 需 退出 。 


实际 上 ，Kubermetes 利 用 了 Docker 的 容器 网 络 共 享 能 力 ，Web Pod 
中 的 容 絮 类 似 于 使 用 以 下 命令 运行 ， 而 Pod 的 PodIP 便 是 网 络 容 器 的 
IP: 


$ docker run -p 80:80 -p 8080:8080 --name network-container -d 
gcr.io/google containers/ pause:0.8.0 

$ docker run - -net container:network-container -d 
jonlangemak/docker:web container 80 

$ docker run - net container:network-container -d 


jonlangemak/docker:web container 8080 


这 样 一 来 ，Pod 中 的 所 有 容器 都 征 互 通 的 ， 而 Pod 对 外 可 以 看 成 一 
个 完整 网 络 单 元 ， 如 图 9-2 所 示 。 


图 9-2 ”Pod 中 的 容器 网 络 


9.4 Pod 间 通信 
Kubernetes 网 络 模型 是 一 个 局 平 化 的 网 络 平面 ， 在 这 个 网 络 平面 
内 ，Pod 作 为 一 个 网 络 单 元 同 Kubernetes Node 的 网 络 处 于 同一 层级 。 


我 们 考虑 一 个 最 小 的 Kubermetes 网 络 拓扑 ， 如 图 9-3 所 示 ， 在 这 个 
网 络 拓 扑 中 满足 以 下 条 件 。 


Node2 


| dockere dockere 


Kj9-3 ”Kubernetes 网 络 拓扑 


。Pod 间 通信 : Pod1 和 Pod2 ( 同 主机 ) ，Pod1 和 Pod3 ( 跨 主 机 ) 能 
够 通信 。 


ay 


。Node 与 Pod 间 通信 : Nodel 和 Pod1/ Pod2 ( 同 主机 ) , Pod3 (& 
主机 ) 能 够 通信 。 


那么 第 一 个 问题 是 如 何 保证 Pod 的 PodIP 是 全 局 唯一 的 。 其 实 做 法 
也 很 简单 ， 为 Pod 的 PodIP 是 Docker 网 桥 分 配 的 ， 所 以 将 不 同 
Kubernetes Node 的 Docker 网 桥 配 置 成 不 同 的 IP 网 段 即 可 。 


另外 ， 同 一 个 Kubernetes Node 上 的 Pod/ 容 器 原生 能 通信 ， 但 是 
Kubernetes Node 之 间 的 Pod/ 容 器 是 如 何 通 信和 的 ， 这 就 需要 对 Docker 进 
行 增强 ， 在 容器 集群 中 创建 一 个 履 盖 网 络 (Overlay Network) ， 联 通 
各 个 节点 ， 目 前 可 以 通过 第 三 方 网 络 插件 来 创建 履 盖 网 络 ， 比 如 


Flannel 和 Open vSwitch 等 。 


9.4.1 FlannelS:EiKubernetes78 mm W258 


Flannelzé HCoreOSMIBLixit FAWN s 23 LA, Ete 
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现在 我 们 利用 Flannel 联 通 两 个 Kubernetes Node， 如 表 9-1 所 示 。 


表 9-1 Kubernetes Node 信 息 


节点 主机 名 IP 
Kubernetes Node 1 kube-node-1 192.168.3.147 
Kubernetes Node 2 kube-node-2 192.168.3.148 


Flannel 使 用 Etcd 作 为 配置 和 协调 中 心 ， 在 运行 Flannel 之 前 需要 在 
Etcd 中 进行 配置 。Flannel 的 Etcd 配 置 目录 可 以 通过 启动 参数 -etcd-prefix 


指定 ， 默 认 是 /coreos.com/network。 


首先 需要 在 Etcd 上 配置 Flannel 网 络 信息 : 


$  etcdctl set /coreos.com/network/config '{ "Network": 


"10.0.0.0/16" }' 


配置 完成 后 ， 在 Kubernetes Node 上 运行 Flannel，Flannel 在 初次 启 
动 的 时 候 会 检查 Etcd 中 的 配置 ， 然 后 为 当前 节点 分 配 可 用 的 IP 网 段 ， 
然后 在 Etcd 中 创建 一 个 路 由 表 ， 通 过 Etcd 查 询 路 由 表 : 


$ etcdctl ls /coreos.com/network/subnets 
/coreos.com/network/subnets/10.0.10.0-24 


/coreos.com/network/subnets/10.0.62.0-24 


$ etcdctl get /coreos.com/network/subnets/10.0.62.0-24 
{"PublicIP":"192.168.3.147"} 


$ etcdctl get /coreos.com/network/subnets/10.0.10.0-24 
{"PublicIP":"192.168.3.148"} 


Flanel 在 分 配 到 P 网 段 之 后 ， 会 创建 一 个 虚拟 网 卡 ， 在 
Kubernetes Node 1 上 查询 Flannel 虚 拟 网 卡 : 


$ ip addr show flannel.1 
5: flannel.1: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1450 
qdisc noqueue state UNKNOWN 
link/ether 62:71:56:28:bd:dd brd ff:ff:ff:ff:ff:ff 
inet 10.0.62.0/16 scope global flannel.1 
valid lft forever preferred lft forever 
inet6 fe80::6071:56ff:fe28:bddd/64 scope link 


valid lft forever preferred lft forever 


另外 ，Flannel 会 配置 Docker 网 桥 (docker0) ， 实 际 上 就 是 通过 修 
改 Docker 的 局 动 参数 --bip 来 实现 。 这 样 一 来 ， 集 群 中 每 个 节点 的 
Docker PY Pri Boe T SPE AIP ES, Mm BEL RA AS SR DE 
拥有 全 局 唯一 的 卫 ， 比 如 在 Kubernetes Node 1 上 查询 Docker 网 桥 : 


$ ip addr show dockerO 
6: dockerO: <NO-CARRIER , BROADCAST, MULTICAST, UP» mtu 1450 
qdisc noqueue state DOWN 
link/ether 56:84:7a:fe:97:99 brd ff: ff: ff: fF: ff: fF 
inet 10.0.62.1/24 scope global dockerO 
valid lft forever preferred lft forever 
inet6 fe80::5484:7aff:fefe:9799/64 scope link 


valid lft forever preferred lft forever 


由 此 ，Flannel 为 两 个 Kubernetes Node 划 分 好 了 容器 网 络 网 段 ， 如 


表 9-2 所 示 。 


329-2 Kubernetes Node 容 器 网 络 网 段 划 分 (Flannel) 


节点 主机 名 IP Docker Ht 


Kubernetes 
Node 1 


kube-node-1 192.168.3.147 10.0.62.1/24 


10.0.10.1/24 


Kubernetes 
kube-node-2 192.168.3.148 
Node 2 


除 此 之 外 ，EFlannel 会 修改 路 由 表 ， 使 得 Flannel 虚 拟 网 卡 可 以 接管 
容器 跨 主 机 的 通信 。 在 Kubermetes Node 1 上 查询 路 由 表 : 


$ route -n 
Kernel IP routing table 


Destination Gateway Genmask Flags Metric 


Ref Use Iface 


10.0.0.0 0.0.0.0 255.255.0.0 U 9 
0 0 flannel.1 

10.0.62.0 0.0.0.0 255.255.255.0 U 0 
0 © dockerO 


TEKubernetes Node 2 上 查询 路 由 表 : 


$ route -n 


Kernel IP routing table 


Destination Gateway Genmask Flags Metric 
Ref Use Iface 

10.0.0.0 0.0.0.0 255.255.0.0 U 0 
0 0 flannel.1 

10.0.10.0 0.0.0.0 255.255.255.0 U 0 
0 © dockerO 


这 样 一 来 ， 当 一 个 万 点 的 容 需 访问 另 一 个 节点 的 容器 时 ， 源 和 点 
上 的 数据 会 从 docker0 网 桥 路 由 到 flannel1.1 网 卡 ， 在 目的 节点 会 从 
flannel 1.1 网 卡 路 由 到 docker0 网 桥 。 比 如 现在 有 一 个 数据 包 要 从 IP 为 
10.0.62.2 的 容器 发 到 IP 为 10.0.10.2 的 容器 ， 根 据 Kubernetes Node 1 的 路 
由 表 ， 它 只 与 10.0.0.0/16 这 条 记录 匹配 ， 因 此 数据 包 从 docker0 网 桥 出 
来 以 后 就 被 路 由 到 了 flannel1.1 网 卡 。 同 理 ， 在 Kubernetes Node 2 |, 
由 于 目的 地 址 匹配 在 docker0 网 桥 对 于 的 10.0.10.0/24 这 个 记录 上 ， 数 据 
包 从 flannel1.1 网 卡 出 来 以 后 就 袖 路 由 到 了 docker0 网 桥 ， 最 后 转发 给 


w 
标 容 器 。 


Flannel 虚 拟 网 卡 接收 到 的 数据 包 会 被 Flannel 服 务 进行 封装 ， 
Flannel 将 通过 隧道 协议 封装 这 些 数 据 包 ， 目 前 隧道 协议 已 经 文 持 
UDP、VxLAN 等 ， 默 认 是 UDP。 当 容器 跨 主 机 通信 的 时 候 ， 源 主机 的 
Flannel 服 务 将 接收 到 的 数据 包 包 装 在 另 一 种 网 络 包 中 ， 然 后 目的 主机 
的 Flannel 服 务 再 进行 解 包 。 


最 终 ，Flannel 将 运行 在 所 有 Kubernetes Node 上 ，Flannel 重 新 规划 
容 需 集群 网 络 ， 从 而 使 得 集群 中 所 有 容 需 能 够 获得 同属 一 个 内 网 且 不 
重复 的 卫 ， 并 证 属于 不 同和 节 点 上 的 容器 能 够 直接 通过 内 网 卫 通 信 ， 
Flannel 实 现 的 网 络 结构 如 图 9-4 所 示 。 
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9.4.2 ”使 用 Open vSwitchSCJlKubernetes 
履 关 网络 


Open vSwitch 是 一 个 高 质量 的 、 多 层 虚 拟 交 换 机 ， 使 用 开源 
Apache 2.0 许 可 协议 ， 由 Nicira Networks 开 发 。 它 的 日 的 是 让 大 规模 网 
络 目 动 化 可 以 通过 编程 扩展 ， 同 时 仍然 支持 标准 的 管理 接口 和 协议 。 


Open vVSwitch 也 提供 了 对 OpenFlow 协 议 的 文 持 ， 用 户 可 以 使 用 任 
何 文 持 OpenFlow 协 议 的 控制 器 对 Open vSwitch 进 行 远 程 管理 控制 。 
Open vSwitch 是 一 项 非常 重要 的 SDN 技 术 ， 可 以 灵活 地 创建 出 满足 各 
种 需求 的 虚拟 网 络 ， 也 包括 Kubernetes 中 的 窗 盖 网 络 。 


现在 我 们 利用 Open vSwitch 联 通 两 个 Kubernetes Node。 为 了 保证 
容器 IP 不 冲突 ， 所 以 必须 规划 好 Kubernetes Node 上 Docker 网 桥 的 网 
段 ， 如 表 9-3 所 示 。 


表 9-3 Kubernetes Node 容 器 网 络 网 段 划 分 (Open vSwitch) 


节点 Docker 网 桥 


Kubernetes 
Node 1 


kube-node-1 192.168.3.147 10.246.0.1/24 


Kubernetes 
kube-node-2 192.168.3.148 10.246.1.1/24 
Node 2 


Open vSwitch 实 现 的 网 络 模 型 如 图 9-5 所 示 。 
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图 9-5 Open vSwitch 实 现 Kubernetes 覆 盖 网 络 


1. 首先 设置 Docker 网 桥 : 
* Kubernetes Node 1 


brctl addbr dockerO 
ip link set dev dockerO up 


ifconfig dockerO 10.246.0.1 netmask 255.255.255.0 up 


* Kubernetes Node 2 


brctl addbr dockerO 
ip link set dev dockerO up 


ifconfig dockerO 10.246.1.1 netmask 255.255.255.0 up 


2. 然后 创建 Open vSwitch 虚 拟 网 桥 obr0， 连 接 各 个 网 络 设备 : 


* Kubernetes Node 1 


# 创 建 obrg 
$ ovs-vsctl add-br obrO -- set Bridge obrO fail-mode=secure 


$ ovs-vsctl set bridge obrO protocols-OpenFlow13 


# 创 建 GRE 隧 道 


$ ovs-vsctl add-port obrO greO \ 
-- set Interface greo type-gre options:remote ip-flow 


options:key-flow ofport request-10 


# 创 建 tun0 连 接 docker0 和 obrg 

$  ovs-vsctl add-port obrO tunO -- set Interface  tunO 
type-internal ofport request-9 

$ brctl addif dockerO tuno 


$ ip link set tunO up 


# 设 置 0penFLow 规 则 


$ ovs-ofctl -0 OpenFlowi13 del-flows obrO 

$ ovs-ofctl -0 OpenFlow13 add-flow obrO \ 

table=0, ip, in_port=10, nw_dst=10.246.0.1/24, actions=output:9 

$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 

table=0, arp, in_port=10, nw_dst=10.246.0.1/24, actions=output:9 

$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 

table=0, in_port=9, ip, nw_dst=10.246.1.1/24,actions=set_field:192 
.168.3.149->tun_dst, output :10 

$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 

table=0, in_port=9, arp, nw_dst=10.246.1.1/24, actions=set_field:19 


2.168.3.149->tun_dst, output:10 


e Kubernetes Node 2 


# 创 建 obrg 


$ ovs-vsctl add-br obrO -- set Bridge obrO fail-mode=secure 


$ ovs-vsctl set bridge obrO protocols-OpenFlow13 


# 创 建 GRE 隧 道 


$ ovs-vsctl add-port obrO greO \ 


-- set Interface | greO  type=gre 


options:key-flow ofport request-10 


# 创 建 tun9 连 接 docker0 和 obrg 

$  ovs-vsctl add-port obr0 tun0 -- 
type=internal ofport_request=9 

$ brctl addif dockerO tuno 


$ ip link set tunO up 


# 设 置 0penFLow 规 则 


$ ovs-ofctl -0 OpenFlow13 del-flows obrO 


$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 
table=0, ip, in_port=10, nw_dst=10.246.1.1/24, actions=output:9 


$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 


options:remote ip-flow 


set 


Interface 


tuno 


table=0, arp, in_port=10, nw_dst=10.246.1.1/24, actions=output:9 


$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 


table=0, in_port=9, ip, nw_dst=10.246.0.1/24, actions=set_field:192 


.168.3.148->tun_dst, output:10 


$ ovs-ofctl -0 OpenFlowi13 add-flow obrO \ 


table=0, in_port=9, arp, nw_dst=10.246.0.1/24, actions=set_field:19 
2.168.3.148->tun_dst, 


output:10 


3. 最 后 配置 路 由 : 


e Kubernetes Node 1 


$ ip route add 10.246.0.0/16 dev dockerO scope link src 


10.246.0.1 


e Kubernetes Node 2 


$ ip route add 10.246.0.0/16 dev dockerO scope link src 


10.246.1.1 


9.5 ”Service 人 到 Pod 通信 


Service 在 Pod 之 间 起 到 服务 代理 的 作用 ， 对 外 表现 为 一 个 单一 访 
问 接 口 ， 将 请 求 转 发 给 Pod，Service 的 网 络 转 发 是 Kubernetes 实 现 服务 
编排 的 关键 一 环 。 


现在 有 一 个 Service， 查 询 详情 如 下 : 


$ kubectl describe service myservice 
Name: myservice 
Namespace: default 


Labels: <none> 


Selector: name=mypod 

Type: ClusterIP 

IP: 10.254.206.148 

Port: http 80/TCP 

Endpoints: 10.0.62.87:80,10.0.62.88:80,10.0.62.89:80 
Session Affinity: None 


No events. 


可 以 看 到 ， 该 Service 的 虚拟 IP 是 10.254.206.148， 端 口 80/TCP 对 应 
的 Endpoints 包含 3 个 后 3m : 10.0.62.87:80 ^ 10.0.62.88:80 和 
10.0.62.89:80 ， 即 当 请 求 10.254.149.17:80 时 ， 会 转发 到 这 些 后 端 之 


— Q0 


Bi Je Hz TULIP x EH Kubernetes fi] @ HJ , He FLIP AY P] Ex: Ze O8 E 
Kubernetes API Server 的 启动 参数 --service-cluster-ip-range=10.254.0.0/16 
配置 的 。 


男 一 个 关键 组 件 是 Kubernetes Proxy, Kubernetes Proxy 组 件 负责 实 
现 虚 拟 IP 路 由 和 转发 ， 而 在 容器 覆盖 网 络 之 上 又 实现 了 Kubernetes 层 级 
的 虚拟 转发 网 络 。Kubernetes Proxy 需 要 满足 以 下 功能 


。 转 发 访问 Service 的 虚拟 卫 的 请 求 到 Endpoints ° 
。 监 控 Service 和 Endpoints 的 变化 ， 实 时 刷新 转发 规则 。 
。 提供 负 载 均衡 能 力 。 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Kubemetes Proxy 有 两 种 实现 
机 制 : Userspace 和 Iptables， 可 以 通过 Kubernetes Proxy 的 启动 参数 -- 


proxy-mode 指 定 。 


9.5.1 Userspace AIÑ 


{£ Userspacetizzt, F, Kubernetes Proxy 将 会 为 每 一 个 Service 在 主机 
上 启用 随机 端口 进行 监听 ， 并 且 创 建 Iptables 规 则 重 定 回访 问 Service 虚 
拟 IP 的 请 求 到 这 个 端口 上 ， 而 Kubernetes Proxy 将 请 求 转发 到 
Endpoints。 在 此 模式 下 ，Kubernetes Proxy 起 到 有 反 疝 代理 的 作用 ， 请 求 
的 转发 由 Kubernetes Proxy 在 用 户 空间 下 完成 。Kubermetes Proxy 需 要 监 
控 Endpoints 的 变化 ， 实 时 刷新 转发 规则 ， 如 图 9-6 所 示 。 
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Node 


SemiceVIP 1 |  [NNEESEESZGGENM ' Kubernetes API. | 
10.254.206.148 'Kubernetes Proxy RODEO aa 


Iptables A cememememsm| — (ANN UNF RT ASS aT WOT UN UEM 


图 9-6 Kubernetes Proxy 的 Userspace 模 式 


当前 Kubernetes Proxy 只 是 3 层 (TCP/UDP Over IP) 转发 ， 默 认 的 
负载 均衡 策略 是 轮 询 方式 。 


通过 iptables-save 命 令 可 得 询 关 于 Service myservice 的 Iptables 规 
Ml: 


$ iptables-save|grep myservice 

-A KUBE-PORTALS-CONTAINER -d 10.254.206.148/32 -p tcp -m 
comment --comment 

"default/myservice:http" -m tcp --dport 80 -j REDIRECT --to- 
ports 35841 

-A KUBE-PORTALS-HOST -d 10.254.206.148/32 -p tcp -m comment -- 
comment 

"default/myservice:http" -m tcp --dport 80 -j DNAT --to- 


destination 192.168.3.146:35841 


Kubernetes Proxy 会 为 Service 创 建 两 条 Iptables 规 则 ， 其 中 包含 如 下 
两 个 Iptables 自 定义 链 。 


e KUBE-PORTALS-CONTAINER: 用 于 匹配 容器 发 出 的 报 文 ， 绑 
定 在 NAT 表 PREROUTING 链 。 


e KUBE-PORTALS-HOST: 用 于 匹配 答 主 机 发 出 的 报 文 ， 绑 定 在 
NAT 表 OUTPUT 链 。 


对 于 Service myservice， 两 条 Iptables 规 则 的 作用 都 是 为 了 将 目的 了 
为 10.254.206.148/32， 并 且 目 的 端口 为 80 的 报 文 重 定 回 到 本 机 的 35841 
端口 ， 而 35841 端 口 就 是 Kubernetes Proxy 监 听 的 端口 ，Kubernetes 
Proxy 监 听 在 35841， 作 为 反 回 代理 将 请 求 转发 到 Service myservice 的 
Endpoints。 


$ lsof -i:35841 
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE 
NAME 


kube-proxy 1040 root 5u IPv6 20457 Oto TCP 


*:51056 (LISTEN) 


9.5.2 ”Iptables 模 式 


在 Iptables 模 式 下 ，Kubernetes Proxy 则 是 完全 通过 创建 Iptables 规 
则 ， 直 接 重 定 癌 访问 Service 虚 拟 IP 的 请 求 到 Endpoints。 而 当 Endpoints 
发 生变 化 的 时 候 ，Kubernetes Proxy 会 刷新 相关 的 Iptables 规 则 。 在 此 模 
式 下 ，Kubernetes Proxy 只 是 负责 监控 Service 和 Endpoints， 更 新 Iptables 
规则 ， 报 文 的 转发 依赖 于 Linux 内 核 ， 默 认 的 负载 均衡 策略 是 随机 方 
式 ， 如 图 9-7 所 示 。 
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图 9-7 Kubernetes Proxy 的 Iptables 模 式 


通过 iptables-save 命 令 可 查询 到 关于 Service myservice 的 Iptables 规 
Ml: 


$ iptables-save|grep myservice 

-A KUBE-SEP-5534AF2Y644GLPZI -s 10.0.62.87/32 -m comment -- 
comment "default/myservice: 

http" -j MARK --set-xmark 0x4d415351/0xffffffff 

-A KUBE-SEP-5534AF2Y644GLPZI -p tcp -m comment  --comment 
"default/myservice:http" -m tcp 

-j DNAT --to-destination 10.0.62.87:80 

-A KUBE-SEP-5UWZC74U4HN6VNI5 -s 10.0.62.88/32 -m comment -- 
comment "default/myservice: 

http" -j MARK --set-xmark 0x4d415351/0xffffffff 

-A KUBE-SEP-5UWZC74U4HN6VNI5 -p tcp -m comment  --comment 
"default/myservice:http" -m tcp 

-j DNAT --to-destination 10.0.62.88:80 

-A KUBE-SEP-W2TMLVNCN2RGF2MT -s 10.0.62.89/32 -m comment -- 
comment "default/myservice: 

http" -j MARK --set-xmark 0x4d415351/0xffffffff 

-A  KUBE-SEP-W2TMLVNCN2RGF2MT -p tcp -m comment --comment 
"default/myservice:http" -m tcp 

-j DNAT --to-destination 10.0.62.89:80 

-A KUBE-SERVICES -d 10.254.206.148/32 -p tcp -m comment -- 
comment "default/myservice:http 

cluster IP" -m tcp --dport 80 -j MARK --set-xmark 
Ox4d415351/0xffffffff 

-A KUBE-SERVICES -d 10.254.206.148/32 -p tcp -m comment -- 
comment "default/myservice:http 

cluster IP" -m tcp --dport 80 -j KUBE-SVC-YZPZUSJVGCLDKDHP 


-A KUBE - SVC - YZPZUS JVGCLDKDHP -m comment - comment 


"default/myservice:http" -m statistic 


--mode random --probability ©. 33332999982 -j KUBE - SEP - 
5534AF2Y644GLPZI 
-A KUBE - SVC - YZPZUS JVGCLDKDHP -m comment --comment 


"default/myservice:http" -m statistic 


--mode random --probability ©. 50000000000 -j KUBE -SEP - 
5UWZC74U4HN6VNI5 
-A KUBE - SVC - YZPZUS JVGCLDKDHP -m comment --comment 


"default/myservice:http" -j 
KUBE -SEP -W2TMLVNCN2RGF2MT 


Kubernetes Proxy 会 为 Service 创 建 一 系列 Iptables 规 则 ， 其 中 包含 
Iptables 目 定义 链 。 


e KUBE-SERVICES: 绑 定 在 NAT 表 PREROUTING 链 和 OUTPUT 
BE o 


e KUBE-SVC-*: {t3#—‘ Service, 4832 7EKUBE-SERVICES ° 


e KUBE-SEP-*: 代表 Endpoints 的 每 一 个 后 端 ， 绑 定 在 KUBE- 
SVC-* » 


对 于 Service myservice, ServiceX M HY Iptables FH XE X HE Ze KUBE- 
SVC-YZPZUSJVGC- LDKDHP, ，Endpoints 对 应 的 Iptables 自 定义 链 是 
KUBE-SEP-5534AF2Y644GLPZI ` KUBE-SEP- 5UWZC74U4HN6VNI5 
TIKUBE-SEP-W2TMLVNCN2RGF2MT 。 


通过 iptables 碍 询 可 以 更 加 清晰 地 看 出 转发 的 规则 : 


$ iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 


target prot opt source 


KUBE -SERVICES all ix 0.0.0.0/0 


kubernetes service portals */ 


Chain INPUT (policy ACCEPT) 


target prot opt source 


Chain OUTPUT (policy ACCEPT) 

target prot opt source 

KUBE - SERVICES all o 0.0.0.0/0 
kubernetes service portals */ 

Chain POSTROUTING (policy ACCEPT) 
target prot opt source 
MASQUERADE all DE 0.0.0.0/0 


kubernetes service traffic 


requiring SNAT */ mark match 0x4d415351 


Chain KUBE-SERVICES (2 references) 
target prot opt source 
MARK tcp -- 0.0.0.0/0 


default/myservice:http 


destination 


0.0.0.0/0 Ee 


destination 


destination 


0.0.0.0/0 /* 


destination 
0.0.0.0/0 /* 

destination 
10.254.206.148 /* 


cluster IP */ tcp dpt:80 MARK set 0x4d415351 


KUBE - SVC - YZPZUS JVGCLDKDHP tcp 
10.254.206.148 /* default/ 


myservice:http cluster IP */ tcp dpt:80 


"e 0.0.0.0/0 


Chain KUBE-SVC-YZPZUSJVGCLDKDHP (1 references) 


target prot opt source destination 
KUBE -SEP - 5534AF2Y644GLPZI all as 
0.0.0.0/0 /* default/ 

myservice:http By statistic mode random 


0. 33332999982 


KUBE - SEP-SUWZC74U4HN6VNIS all EAS 
0.0.0.0/0 /* default/ 
myservice:http "y statistic mode random 


0.50000000000 
KUBE - SEP - W2TMLVNCN2RGF2MT all ix 
0.0.0.0/0 /* default/ 


myservice:http */ 


Chain KUBE-SEP-5534AF2Y644GLPZI (1 references) 
target prot opt source destination 
MARK all -- 10.0.62.87 

/* default/myservice:http */ 

MARK set 0x4d415351 

DNAT tcp ES 0.0.0.0/0 

/* default/myservice:http */ 


tcp to:10.0.62.87:80 


Chain KUBE-SEP-5UWZC74U4HN6VNI5 (1 references) 
target prot opt source destination 


MARK all -- 10.0.62.88 0.0.0.0/0 


0.0.0.0/0 


probability 


0.0.0.0/0 


probability 


0.0.0.0/0 


0.0.0.0/0 


0.0.0.0/0 


/* 


default/myservice:http */ 

MARK set 0x4d415351 

DNAT tcp sue 0.0.0.0/0 
/* default/myservice:http */ 


tcp to:10.0.62.88:80 


Chain KUBE-SEP-W2TMLVNCN2RGF2MT (1 references) 
target prot opt source destination 
MARK all -- 10.0.62.89 

/* default/myservice:http */ 

MARK set 0x4d415351 

DNAT tcp ge 0.0.0.0/0 

/* default/myservice:http */ 

tcp to:10.0.62.89:80 


0.0.0.0/0 


0.0.0.0/0 


0.0.0.0/0 
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安全 永远 是 一 个 重大 的 话题 ， 特 别 是 对 于 Kubernetes 这 样 的 云 计 
算 平 台 ， 更 需要 设计 出 一 套 完善 的 安全 方案 ， 以 应 对 复杂 的 场景 。 本 


章 将 前 述 Kubernetes 的 安全 保障 机 制 ， 主 要 包括 Kubernetes API 的 安全 
访问 、 容 器 安全 和 多 租户 。 


10.1 Kubernetes 安 全 原则 


Kubernetes 设 计 出 了 一 套 API 和 敏感 信息 处 理 方 案 ， 也 提供 了 容 絮 
安全 保障 ， 以 下 是 Kubemetes 的 安全 设计 原则 : 


* 剑 证 容 右 与 其 运行 的 答 主 机 之 间 有 了 明确 的 隔离 。 


* 限制 容 右 对 基础 设施 或 者 其 他 容器 造成 不 民 影 响 。 


- 最 小 特权 原则 一 一 限定 每 个 组 件 只 被 赋 予 执行 操作 所 必需 的 最 
小 特权 ， 由 此 确保 可 能 产生 的 损失 最 小 。 


* 普通 用 户 明 确 区 别 于 系统 管理 员 。 
© 能 够 给 普通 用 户 赋予 管理 权限 。 


- 应 用 能 够 安全 地 获取 敏感 信息 。 


10.2 Kubernetes API 的 安全 访问 


Kubernetes API Server 是 Kubernetes 系 统 的 入 口 ， 以 REST API 接 口 
方式 提供 给 外 部 客户 和 内 部 组 件 调 用 ， 对 于 Kubernetes API 的 访问 调用 
需要 进行 严格 管控 ， 保 证 系统 的 安全 。 


10.2.1 HTTPS 


Kubernetes API Server 采 用 的 是 REST 模 式 的 API 服 务 ，REST 利 用 
传统 Web 特 点 ， 提 出 了 一 个 既 适 于 客户 端 应 用 又 适 于 服务 端 应 用 的 统 
一 架构 ， 极 大 程度 上 统一 及 简化 了 网 站 架构 设计 。 


REST 的 全 称 是 Representational State Transfer ， 表 示 表 述 性 状态 传 
递 ， 无 须 Session， 为 了 安全 ， 每 次 请 求 都 得 带 上 刁 份 认证 信息 。REST 
是 基于 HTTP 的 ， 也 是 无 状态 的 ，HTTP 是 明文 传输 的 ， 所 以 建议 所 有 
的 请 求 都 通过 HTTPS 发 送 ， 保 证 对 于 系统 中 的 重要 数据 做 SSL 加 密 传 
输 ， 如 证 书 、 账 号 密码 等 。 


Kubernetes API Server 支 持 HITP 和 HTTPS， 相 关 启 动 参数 如 表 10- 
1 所 示 。 


3210-1 Kubernetes API Server 的 启动 参数 


BH 说 明 

--insecure-bind-address=127.0.0.1 HTTP (FZE) 绑 定 的 本 机 地 址 ，0.0.0.0 表 示 监 听 本 机 的 所 有 
地 址 ， 默 认 是 127.0.0.1 

--insecure-port=8080 不 安全 端口 ，HTTP《〈 不 安全 ) 绑 定 的 本 机 端口 ， 默 认 是 8080 

--bind-address=0.0.0.0 HTTPS C&4) 绑 定 的 本 机 地 址 ， 默 认 是 0.0.0.0 

--secure-port=6443 AGA, HTTPS CAE) 绑 定 的 本 机 端口 ， 默 认 是 6443， 当 
为 0 时 ， 不 启动 HTTPS 

-tls-cert-file="" HTTPS 需 要 使 用 的 x509 证 书 ， 和 --tls-private-key-file 对 应 。 
当 -tls-cert-file 和 --tls-private-key-file 都 为 空 的 时 候 ， 会 自动 生成 
自 签名 证 书 和 私 钥 ， 生 成 目录 /var/ran/kubernetes 

--tls-private-key-file="" HTTPS 需 要 的 x509 私 钥 ， 和 --tls-cert- 包 对 应 


Kubernetes API Server 开 启 HTTPS 需 要 准备 的 HTTPS 证 书 ， 建 议 从 
权威 CA 机 构 申 请 : 


--tls-cert-file=/path/to/cert 
--tls-private-key-file=/path/to/key 
--secure-port=6443 


--bind-address=0.0.0.0 


因为 HTTP 是 不 安全 的 ， 所 以 应 该 限制 HITP 的 访问 ， 比 如 设置 防 
火 墙 规格 、 防 止 不 信任 域 的 访问 ， 其 中 最 简单 的 方法 是 只 允许 本 机 访 
fa]: 


--insecure-port=8080 


--insecure-bind-address=127.0.0.1 


10.2.2 ”认证 与 授权 


Kubernetes API Server 目 前 支持 认证 (Authentication) 和 授权 
( Authorization) 机 制 进行 安全 访问 控制 。 认 证 和 授权 只 作用 于 


Kubernetes API Server 的 安全 端口 (--secure-port) ， 非 安全 端口 (-- 
insecure-port) 不 受 约束 。 


10.2.2.1 认证 


Basic Authentication 


Basic Authentication 是 指 客户 端 在 使 用 HTTP 访 问 受 限 资源 时 ， 必 
须 使 用 用 户 名 和 密码 以 获取 认证 。 这 是 认证 中 最 简单 的 方法 ， 长 期 以 
来 ， 这 种 认证 方法 被 广泛 使 用 。 当 通过 HTTP 访 问 一 个 使 用 Basic 
Authentication 保 护 的 资源 时 ， 服 务 句 通常 会 在 HTTP 请 求 的 响应 中 加 入 
一 个 “401 需 要 身份 验证 ”的 头 域 ， 来 通知 客户 提供 用 户 任 证， 以 使 用 资 
源 。 如 果 正 在 使 用 浏览 器 访问 需要 认证 的 资源 ， 浏 览 器 会 弹出 一 个 窗 
口 ， 让 你 输入 用 户 名 和 和 密码， 如 有 果 所 输入 的 用 户 名 在 资源 使 用 者 的 验 
证 列表 中 ， 并 且 密 码 完 全 正确 ， 此 时 ， 用 户 才 可 以 访问 受 限 的 资源 。 
但 是 这 种 方式 安全 性 较 低 ， 束 是 简单 地 将 用 户 名 和 密码 进行 Base64 编 
码 放 到 头 域 中 。 正 是 因为 是 Base64 编 码 存 储 ， 最 好 使 用 HTTPS 进 行 加 
密 传输 。 


Kubernetes API Server} /ri Basic Authentication 需要 提供 一 个 CSV 
格式 的 文件 用 于 设置 用 户 列 表 ， 每 行 表示 一 个 用 户 ， 共 3 列 : 密码 、 用 
户 名 和 用 户 ID， 以 下 是 一 个 示例 : 


basic_auth.csv 


admin_passwd, admin, 1 


test_passwd, test, 2 


然后 设置 Kubernetes API Server 的 启动 参数 : 


--basic-auth-file=/path/to/basic_auth.csv 


Token Authentication 


Token 是 一 个 用 户 自 定义 的 任意 字符 串 ， 具 有 随机 性 、 不 可 预测 
性 ， 相 比 于 密码 更 加 安全 ， 一 般 黑 客 或 软件 无 法 猜测 出 来 。Token 
Authentication 实 际 上 同 Basic AuthenticationZS fJ], f Fd Token ER ALIE 7 
密码 ， 可 在 一 定 程度 上 提高 安全 性 。 


Kubernetes API Server 支 持 Token Authentication, FN% 5i E EE t 
个 CSV 格 式 的 文件 用 于 设置 用 户 列表 ， 每 行 表示 一 个 用 户 ， 共 3 列 : 
Token、 用 户 名 和 用 户 ID， 以 下 是 一 个 示例 : 


token_auth.csv 


ceG1x8PkwDz0Z5LsOe1DShpCD1j67r0a, admin, 1 


5OEhn1YY6V7J31m3wZX1TZp8XFXOAHXJ, test, 2 


其 中 Token 是 任意 字符 串 ， 可 以 用 以 下 命令 生成 : 


$ echo $(cat /dev/urandom | base64 | tr -d "=+/" | dd bs=32 


count=1 2> /dev/null) 


然后 设置 Kubernetes API Server 的 启动 参数 : 


--token-auth-file =/path/to/token_auth.csv 


Client Certificate Authentication 


Client Certificate 是 一 种 用 于 证 明 用 户 身 份 的 客户 端 数字 证 书 ， 如 
果 服 务 端 开启 Client Certificate Authentication, Z2 F? Ymy IR] BJ] 4e BHL S 
要 提供 Client Certificate ° 


Kubernetes API Server 支 持 Client Certificate Authentication， 需 要 提 


供 信 任 的 客户 端 CA 证 书 ， 然 后 配置 局 动 参数 : 


--client-ca-file-/path/to/ca.crt 


OpenID Authentication 


OpenID 十 一 套 以 用 户 为 中 心 的 分 散 式 号 份 认 证 系统 ， 用 户 只 需 注 
册 获 取 OpenID 之 后 ， 就 可 以 凭借 此 OpenID 账 号 在 多 个 系统 之 间 目 由 登 
录 使 用 ， 而 不 需要 在 每 一 个 系统 中 注册 账号 ， 实 现 用 户 认证 。 


Kubernetes API Server 支 持 OpenID Authentication ， 相 关 局 动 参数 
如 下 : 


--oidc-issuer-url-«url» 


--oidc-client-id-«id token» 


Keystone Authentication 


Keystone 是 OpenStack 框 架 中 人 负责 管理 身份 验证 、 服 务 规则 和 服务 
令 牌 功能 的 模块 。 用 户 访问 资源 需要 验证 用 户 的 号 份 气 权限 ， 服 务 执 
行 操 作 也 需要 进行 权限 检测 ， 这 些 都 可 以 通过 Keystone 来 处 理 。 


Kubernetes API Server 文 持 对 接 Keystone 来 实现 认证 ， 相 天 启动 参 
x 
数 如 下 : 


--experimental-keystone-url=<AuthURL> 


10.2.2.2 ”授权 


Kubemetes API Server 在 认证 之 后 ， 通 过 授权 (Authorization) 可 
进一步 进行 安全 访问 控制 。 授 权 可 以 通过 Kubernetes API Server 的 -- 
authorization-mode 启 动 参数 设置 以 下 几 种 模式 : 


e --authorization-mode=AlwaysDeny 
e --authorization-mode=AlwaysAllow 
e --authorization-mode=ABAC 


其 中 AlwaysDeny 表 示 拒 绝 所 有 请 求 ，AlwaysAllow 人 允许 所 有 请 
求 。 


ABAC 是 一 种 基于 属性 的 访问 控制 ， 根 据 设 置 好 的 访问 策略 检查 
请 求 的 属性 ， 不 符合 访问 策略 的 请 求 会 被 拒绝 。 


API 请 求 中 有 5 个 属性 可 以 用 作 访 问 控制 : 


。 用 户 ， 请 求 用 于 认证 的 用 户 ， 比 如 使 用 Basic Authentication 时 , 
用 户 需 要 输入 用 户 名 和 密码 进行 认证 ， 那 么 授权 则 根据 该 用 户 进 行 判 


。 用 户 组 ， 用 户 所 在 的 用 户 组 ， 一 个 用 户 可 以 在 多 个 用 户 组 内 。 


。 请 求 是 否 只 读 ， 比 如 GET 请 求 都 是 只 读 的 。 


。 请 求 访问 的 资源 ， 比 如 /api/vl/namespaces/default/pods 请 求 的 资 
源 是 pods， 一 些 情况 下 资源 为 空 ， 比 如 /version ° 


> GeV tEMNamespace, JEJE YAS FAEM Namespace, [C4 
Node， 那 么 Namespace 即 为 空 。 


当 设 置 为 ABAC 模 式 时 ， 还 需要 指定 策略 文件 (--authorization- 
policy-file) ， 策 略 文件 采用 一 种 One JSON Object Per Line 的 配置 格 
式 ， 即 每 一 行 是 一 个 JSON 格 式 的 策略 ， 用 于 设置 访问 控制 权限 ， 策 上 略 
属性 如 表 10-2 所 示 。 


表 10-2 ABAC 模 式 的 策略 属性 


string 如 果 指 定 ， 需 要 和 请 求 认证 


group string 指定 ， 需 要 和 请 求 认 证 用 户 组 


Teadonly boolean 果 为 tue， 说 明 只 允许 GET 请 求 
resource string 指定 ， 需 要 和 请 求 资源 匹配 


namespace string 指定 ， 需 要 和 请 求 资 源 所 在 Namespace 匹 配 


策略 文件 示例 : 


4 _ admin 拥有 所 有 权限 


{"user":"admin"} 


4 scheduler 拥 有 读 pods 的 权限 


{"user":"scheduler", "readonly": true,"resource": "pods"} 


# scheduler 拥 有 读 写 events 的 权限 


("user":"scheduler","resource": "events "} 


# kubelet 拥 有 读 pods 的 权限 


("user":"kubelet","readonly": true,"resource": "pods"} 


# kubelet 拥 有 读 services 的 权限 


("user":"kubelet","readonly": true,"resource": "services"} 


4 kubelet 拥 有 读 endpoints 的 权限 


{"user":"kubelet", "readonly": true,"resource": "endpoints"} 


# kubelet 拥 有 读 写 events 的 权限 


("user":"kubelet","resource": "events"} 


4 alice 拥 有 namespace projectcaribou 下 的 所 有 权限 


{"user":"alice","namespace": "projectCaribou"} 


# alice 拥 有 namespace projectcaribou 下 的 读 权 限 


("user":"bob","readonly": true,"namespace": "projectCaribou") 


4 cindy 拥 有 namespace projectCaribou 下 的 pods 的 读 权 限 
("user":"cindy","resource": "pods", "readonly": 


true, "namespace": "projectCaribou"} 


10.2.3 YEA Hl Admission Controller 


请 求 在 认证 和 授权 之 后 ，Kubernetes 提 供 了 Admission Controller 进 
一 步 对 请 求 进行 准 入 控制 。Admission Controller 作 为 Kubernetes API 


Server 的 一 部 分 ， 并 以 插件 的 形式 存在 ， 不 过 需要 编译 进 Kubernetes 
API Server 可 执行 程序 才能 使 用 。 


Kubernetes API Server 将 按 顺 序 检查 请 求 ， 如 果 其 中 任何 一 项 没 通 
过 ， 那 么 就 会 拒绝 请 求 。 


Admission Controller 支 持 的 插件 如 表 10-3 所 示 。 


表 10-3 Admission Controller 插 件 


名 称 
AlwaysAdmit 比 插件 允许 所 有 的 请 求 
AlwaysDeny 比 插件 拒绝 所 有 的 请 求 
ServiceAccount 比 插件 用 于 支持 


FService Account 


SecurityContextDeny 比 插件 检查 创建 Pod 的 Security Context 是 否 可 用 ， 不 可 用 的 话 拒绝 


ResourceQuota 比 插件 用 于 支持 Resource Quota， 拒 绝对 于 任何 超过 Resource Quota 的 请 求 
LimitRanger 用 于 


NamespaceLifecycle IB 


个 Namespace 会 删除 该 Namespace 下 所 有 的 资源 (pods, services. 
在 Namespace 被 删除 的 过 程 中 ， 此 插件 将 会 拒绝 任何 试图 在 该 Namespace 下 
建新 资源 的 请 求 。 除 此 之 外 ， 拒 绝 试图 在 不 存在 的 Namespace 下 创建 资源 
的 请 求 


在 Kubernetes API Server 启动 的 时 候 ， 可 以 配置 需要 哪些 
Admission Controller， 以 及 它们 的 顺序 ， 建 议 设 置 为 : 


admission_control=NamespaceLifecycle, LimitRanger, SecurityContex 


tDeny, ServiceAccount, ResourceQuota 


10.3 Service Account 


Service Account 概 念 的 引入 是 基于 这 样 的 使 用 场景 : 运行 在 Pod 里 
的 进程 需要 调用 Kubernetes API 以 及 非 Kubernetes API 的 其 他 服务 。 我 


们 使 用 Service Account 来 为 Pod 提 供认 证 。 


Service Account 和 User Account H] BÉ 2 1H 2 — 4E fx E. EBJIRB, € 
们 的 区 别 如 下 : 


* User Account 通 和 常 是 为 人 类 设计 的， 而 Service Account 则 是 为 运 
行 在 Pod 中 的 应 用 设计 的 。 


* User Account 是 全 局 的 ， 即 可 以 跨 Namespace 使 用 ; 而 Service 
Account 是 限定 Namespace 的 ， 即 仅 在 所 属 的 Namespace 下 使 用 。 


。 创 建 一 个 新 的 User Account 通 党 需要 较 高 的 特权 并 且 需 要 经 过 比 
较 复 杂 的 业务 逻辑 ， 而 Service Account 则 不 然 。 


提示 


开局 Service Account 功 能 ， 要 添加 Service Account Admission 
Controller， 即 设置 Kubernetes API Server 的 启动 参数 : 


--admission control-...ServiceAccount... 


Kubernetes API Server 的 相关 局 动 参数 如 表 10-4 所 示 。 


3210-4 Kubernetes API Server 的 启动 参数 


--service- 配置 一 个 包含 PEM-encoded x509 RSA 的 私 钥 或 者 


account-key- 公 铀 ， 用 于 验证 Service Account Token 


file-" | 


Kubernetes Controller Manager 的 相关 启动 参数 如 表 10-5 所 示 。 


#210-5 Kubernetes Controller Manager 的 启动 参数 


--service-account- 配置 一 个 包含 PEM-encoded x509 RSA 的 私 
private-key-file="" 钥 ， 用 于 签发 Service Account Token 


配置 访问 Kubernetes API Server 的 CA 证 书 ， 
将 赋值 给 Service Account Secret 


Ww 


--root-ca-file= 


10.3.1 使 用 默认 Service Account 


Kubernetes Controller Manager 会 为 每 个 Namespace 默 认 创 建 一 个 
Service Account， 我 们 称 为 默认 Service Account: 


$ kubectl get serviceaccount 
NAME SECRETS AGE 
default 1 1d 


BA Service Account, — 4 Secret: 


$ kubectl describe serviceaccount default 
Name : default 
Namespace: default 


Labels: «none» 


Mountable secrets: default-token-7t9ja 


Tokens: default-token-7t9ja 


Image pull secrets: <none> 


查询 该 Secret: 


$ kubectl describe secret default-token-7t9ja 

Name: default-token-7t9ja 

Namespace: default 

Labels: <none> 

Annotations: kubernetes.io/service- 
account.name-default,kubernetes.io/service- 


account.uid-... 


Type: kubernetes.io/service-account-token 


Data 


token: 


ca.crt: 1838 bytes 


查询 显示 这 是 一 个 kubernetes.io/service-accountrtoken 类 型 的 
Secret， 称 为 Service Account Secret， 包 合 两 个 数据 token 和 ca.crt， 这 也 
是 由 Kubernetes Controller Manager 生 成 的 。 其 中 token 是 由 --service- 
account-private-key-file 指 定 的 密 钥 签 发 生成 的 ， 而 ca.crt 是 由 --root-ca- 
fie 指 定 的 CA 证 书 。 


这 样 一 来 ， 痢 建 的 Pod 如 采 没 有 指定 Service Account, WAE H EA 

认 Service Account ， 挂 载 Service Account Secret 2| 4 s H oe "P 
( /var/run/secrets/kubernetes.io/serviceaccount) ， 了 Pod 中 的 应 用 通过 
token 和 ca.crt 访 问 Kubernetes API Server ° 同时 Kubernetes 提 供 非常 方便 
的 方式 让 Pod 获 取 Kubernetes API Server 的 地 址 。Kubernetes 在 初始 化 的 
时 候 会 创建 一 个 Kubernetes Service, ， 叫 作 kubernetes ， 它 代表 的 就 是 


Kubernetes API Server: 


Kubernetes 在 初始 化 的 时 候 会 创建 一 个 Kubernetes Service, H/F 
kubernetes， 它 代表 的 就 是 Kubernetes API Server: 


$ kubectl describe service kubernetes 

Name: kubernetes 

Namespace: default 

Labels: component=apiserver, provider=kubernetes 
Selector: «none» 

Type: ClusterIP 

IP: 10.254.0.1 

Port: https 443/TCP 

Endpoints:  192.168.3.146:6443 

Session Affinity: None 


No events. 


Kubernetes Service É* fiz TIL IP Æ 10.254.0.1, 3X 2 Kubernetes API 
Server fic Hi 的 Service : Ek AY 9S — A IP ( --service-cluster-ip- 
range-10.254.0.016 ) ， 然 后 将 会 转发 HITPS 的 443 端 口 到 
192.168.3.146:6443 ， 即 Kubernetes API Server 的 地 址 和 HTTPS 安 全 端 


O » JE HKubernetes Service 是 最 早 创 建 的 ， 新 建 的 Pod 中 可 以 通过 环境 
变量 获取 来 访问 Kubernetes API Server (也 可 以 通过 DNS 方 式 ) : 


KUBERNETES SERVICE HOST-10.254.0.1 
KUBERNETES PORT 443 TCP-tcp://10.254.0.1:443 


KUBERNETES PORT 443 TCP PORT-443 


KUBERNETES PORT 443 TCP ADDR-10.254.0.1 


KUBERNETES SERVICE PORT-443 
KUBERNETES PORT-tcp://10.254.0.1:443 
KUBERNETES PORT 443 TCP PROTO-tcp 


Pod 中 的 进程 就 可 以 访问 Kubernetes API Server， 我 们 现在 简单 实 
现 一 个 脚本 curl-k8s- api.sh 来 调用 Kubernetes API: 


#!/bin/sh 


# curl-k8s-api.sh 


Endpoint=$1 

ServiceAccountToken=$(cat 
/var/run/secrets/kubernetes.io/serviceaccount/token) 
ServiceAccountRootCA-/var/run/secrets/kubernetes.io/serviceacco 
unt/ca.crt 
KubernetesServerURL-"https://$KUBERNETES SERVICE HOST:S$KUBERNET 
ES SERVICE PORT" 


curl -XGET -H "Authorization: Bearer $ServiceAccountToken" \ 


--cacert $ServiceAccountRootCA \ 


${KubernetesServerURL}${Endpoint } 


Hil AS curl-k8s-api.sh iz Bt Service Account 的 token 和 ca.crt， 通 过 环境 
变量 生成 URL， 然 后 通过 curl 命 令 调用 Kubernetes API Server。 我 们 需 
要 将 脚本 curl-k8s-apish 放 入 Pod 的 容器 中 ， 然 后 访问 /api 获 取 版 本 信 
E 


JO: 


$ kubectl exec pod -- curl-k8s-api.sh /api 
{ 


"versions": [ 


"y1" 


Jj/h, Service Account 会 目 动 创 建 一 个 认证 用 户 ， 用 户 的 命名 格 


a= 
Pe 
system:serviceaccount: [namespace]: [Serviceaccountname | 


比如 对 于 在 Namespace my-ns'F, FRW Service Account 对 应 的 用 户 
名 是 : 


system:serviceaccount:my-ns:default 


i| R Kubernetes API Server 设 置 了 ABAC 的 授权 模式 ， 需 要 为 
Service Account 设 置 授权 人 策略， 否则 会 导致 Pod 无 法 通过 Service 
Account 访 问 Kubernetes API Server， 比 如 设置 为 只 读 权 限 : 


("user":"system:serviceaccount: my-ns:default", "readonly": 


true} 


10.3.2 ”创建 目 定 义 Service Account 


用 户 可 以 创建 自 定 义 的 Service Account, Service Account 的 定义 文 


件 serviceaccount.yaml: 


apiVersion: vi 
kind: ServiceAccount 
metadata: 


name; my- serviceaccount 


通过 定义 文件 创建 Service Account: 


$ kubectl create -f serviceaccount.yaml 


serviceaccount "my-serviceaccount" created 


查询 Service Account 的 详细 信息 : 


$ kubectl describe serviceaccount my-serviceaccount 
Name: my-serviceaccount 
Namespace: default 


Labels: «none» 


Image pull secrets: <none> 


Mountable secrets: my-serviceaccount-token-ivsmi 


Tokens: my-serviceaccount-token-ivsmi 


可 以 看 到 ， 该 Service Account Ej $$ — Â Service Account Secret , 
Kubernetes Controller Manager 会 保证 每 个 Service Account EVES — 
^l Service Account Secret ° WRAAE EEA E AEH Service Account 
Secret, 可 A F L 8| & , Service Account Secret 的 定义 文件 


serviceaccountSecret.yaml: 


apiVersion: vi 
kind: Secret 
metadata: 
name: my-serviceaccount-secret 
annotations: 
kubernetes.io/service-account.name: my-serviceaccount 


type: kubernetes.io/service-account-token 


通过 定义 文件 创建 Service Account Secret: 


$ kubectl create -f serviceaccountSecret.yaml 


secret "my-serviceaccount-secret" created 


添加 创建 好 的 Service Account Secret#!/Service Account: 


$ kubectl patch serviceaccount my-serviceaccount \ 
-p '{"secrets": [{"name": "my-serviceaccount-secret"}]}' 


"my-serviceaccount" patched 


然后 删除 自动 创建 的 Service Account Secret: 


$ kubectl delete secret my-serviceaccount -token-ivsm1 


secret "my-serviceaccount-token-ivsmi" deleted 


IEE ACA Sth T Service Account Secret: 


$ kubectl describe serviceaccount my-serviceaccount 
Name: my-serviceaccount 
Namespace: default 


Labels: <none> 
Image pull secrets: <none> 
Mountable secrets: my-serviceaccount-secret 


Tokens: my -serviceaccount-secret 


在 Pod 的 定义 中 可 以 通过 .spec.serviceAccountName 18 7€ Service 
Account， 如 下 所 示 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: busybox 
namespace: default 
spec: 


containers: 


- name: busybox 
image: busybox 
command: 

- sleep 
- "3600" 
restartPolicy: Always 


serviceAccountName: my-serviceaccount 


10.3.3 Service Account 添加 Image Pull 
Secret 


T£ Service Account 中 添加 Image Pull Secret], ~4 Pod HiXService 
Account BÉ FY fe at Ao R EX EE F Image Pull Secret; 而 当 为 默认 
Service Account 添 加 Image Pull Secret}, 357 Pod BH ay KEK E: Image 
Pull Secret, MO TRE. © 


首先 创建 一 个 Image Pull Secret, 9| 2754.3.1T: 


$ kubectl get secret myregistrykey 
NAME TYPE DATA AGE 


myregistrykey kubernetes.io/dockercfg 1 1h 


添加 Image Pull Secret#! SA Service Account: 


$ kubectl patch serviceaccounts default \ 
-p '("imagePullSecrets": [("name": "myregistrykey"}]}' 
"default" patched 


修改 默认 Service Account 成 功 后 ， 可 以 查询 到 Image Pull Secretis 
加 成 功 : 


$ kubectl describe serviceaccounts default 
Name: default 

Namespace: default 

Labels: <none> 


Image pull secrets: myregistrykey 
Mountable secrets: default-token-mymp9 


Tokens: default -token-mymp9 


这 样 一 来 ， 新 创建 的 Pod 都 会 目 动 关 联 上 Image Pull Secret: 


spec: 
imagePullSecrets: 


- name: myregistrykey 


10.4 RALE 


10.4.1 Linux Capability 


Docker 对 于 容器 中 的 root 用 户 是 进行 限制 的 ， 这 是 基于 Linux 内 核 
的 Capability 机 制 实现 的 。Linux Capability 将 内 核 系 统 资源 访问 划分 为 
许多 的 权限 属性 ， 从 而 可 以 对 权限 进行 精细 化 管理 。 


对 于 Docker 容 絮 中 的 root 用 户 ， 很 多 系统 相关 的 操作 权限 都 是 被 
剥夺 的 ， 只 具备 超级 用 户 的 一 些 基本 权限 。 如 果 需 要 授予 Docker 容 虱 
足够 的 权限 ， 可 以 使 用 特权 模式 ， 即 设置 docker run 的 参数 -- 


privileged=ture ° 


TE Pod 的 定 Pa id 可 以 通 
过 .spec.containers[].securityContext.privileged=true 1x  Z€ as HJ FF A T 


式 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: nfs-server 
labels: 
role: nfs-server 
spec: 
containers: 
- name: nfs-server 
image: jsafrane/nfs-data 
ports: 
- name: nfs 
containerPort: 2049 
securityContext: 


privileged: true 


注意 


Pod 中 的 容器 要 设置 特权 模式 ， 需 要 设置 Kubernetes API Server 
和 Kubelet 的 启动 参数 --allow-privileged=ture 来 允许 开启 容器 的 特权 
模式 。 


当 Docker 容 絮 设 置 了 特权 模式 之 后 ， 那 么 Docker 容 俐 的 root 权 限 将 
得 到 大 幅度 提升 。 由 于 Docker 容 器 与 答 主 机 处 于 共享 同一 个 内 核 操 作 
系统 的 状态 ， 因 此 Docker 容 右 将 完全 拥有 内 核 的 管理 权限 ， 这 束 存 在 
安全 隐患 。 


JLN JDN 


而 且 对 应 用 程序 来 说 ， 往 往 只 需要 特定 的 权限 ， 比 如 一 个 程序 需 
要 使 用 ping 命 令 ， 这 是 一 个 SUID 命 令 ， 会 以 root 权 限 运 行 ， 而 实际 上 
这 个 程序 只 是 需要 RAW 套 接 字 建 立 必 要 ICMP 数 据 包 ， 除 此 之 外 的 其 
他 root 权 限 对 这 个 程序 都 是 没有 必要 的 。 


Docker 文 持 添 加 和 删除 容器 的 Linux Capability， 即 docker run 命 令 
HJ --cap-add 和 --cap-drop 人 参数。 在 Pod 的 定义 中 可 以 通 
过 .spec.containers[].securityContext.capabilities.add 
FN .spec.containers[].securityContext.capabilities.drop 74s JU H WH Dos Z& 88 AY 
Linux Capability: 


apiVersion: vi 
kind: Pod 
metadata: 
name: nfs-server2 
labels: 
role: nfs-server 


spec: 


containers: 

- name: nfs-server 
image: nginx 
ports: 

- name: nfs 
containerPort: 2049 
securityContext: 
Capabilities: 
add: 
- IPC_LOCK 
- NET_ADMIN 
drop: 
- SETGID 


10.4.2 SELinux 


SELinux (Security Enhanced Linux) 是 Linux 内 核 的 安全 模块 ， 提 
供 了 一 种 灵活 的 强制 访问 控制 系统 。SELinux 拥 有 一 个 灵活 而 强制 性 
的 访问 控制 结构 ， 旨 在 提高 Linux 系 统 的 安全 性 ， 提 供 强 健 的 安全 保 
证 。 

Docker 文 持 使 用 SELinux 进 行 安全 加 固 ， 通 过 SELinux 可 以 根据 类 
别 和 MCS/MLS 等 级 来 区 分 进程 ， 保 护 窒 主机 不 受 容器 影响 。 


docker run 中 通过 --security-opt 可 以 修改 容 絮 的 MCS/MLS 标 签 : 


--security-opt="label:user:USER" 
--security-opt="label:role:ROLE" 
--security-opt="label:type:TYPE" 


--security-opt="label: level: LEVEL" 


THRIHJ, FEPodHy) mE X "P H FEA RIT SEPIUS as MCS/MLS ine: 


securityContext: 

seLinuxOptions: 
user: USER 
role: ROLE 
type: TYPE 


level: LEVEL 


10.5 ”多 租户 


多 租户 是 云 计算 中 的 一 个 重要 能 力 ， 是 云 计算 集中 式 的 数据 中 
心 ， 以 服务 的 形式 提供 给 用 户 。 多 租户 是 共 至 和 隔离 互相 作用 下 的 产 
物 ， 用 户 需要 处 在 不 同 的 租户 下 ， 同 租户 内 部 是 共 孚 的 ， 但 是 不 同 租 
户 之 间 是 隔离 的 。 


Kubermetes 中 的 Namespace 就 是 租户 的 概念 ，Kubernetes 整 个 平台 
的 内 容 通 过 Namespace 划 分 为 多 个 逻辑 平面 ， 不 同 个 人 或 者 团队 在 不 
同 Namespace 中 共享 Kubernetes，Namespace 之 间 互 相 不 感知 。 


Kubernetes 以 Namespace 作 为 管理 单位 ， 可 以 控制 安全 访问 策略 ， 
设置 资源 配额 等 ， 为 此 需要 使 用 Kuberetes 规 划 好 Namespace， 比 如 可 


以 根据 功能 、 区 域 、 部 门 或 者 业务 等 。 


我 们 可 以 像 其 他 API 对 象 一 样 创 建 Namespace，Namespace 定 义 文 


件 development- namespace.yaml: 


apiVersion: vi 
kind: Namespace 
metadata: 
name: development 
labels: 


name: development 


通过 定义 文件 创建 Namespace: 


$ kubectl create -f development -namespace.yaml 


namespace "development" created 


创建 成 功 后 可 以 查询 Namespace: 


$ kubectl describe namespace development 
Name: development 
Labels: name=development 


Status: Active 
No resource quota. 


No resource limits. 


第 11 章 
Kubernetes 资 源 管理 


资源 管理 是 Kubernetes 的 一 个 关键 能 力 ，Kubernetes 需 要 为 应 用 分 配 
足够 的 资源 ， 又 要 防止 应 用 无 限制 使 用 资源 ， 随 着 应 用 规模 数量 级 的 增 
加 ， 这 些 问题 就 显得 至 关 重 要 。 本 章 将 阐述 Kubernetes 资 源 管理 的 模型 
和 具体 实现 方法 ， 包 括 资源 分 配 策 略 和 配额 限制 等 。 


11.1 Kubernetes 资 源 模 型 


虚拟 化 技术 是 云 计算 平台 的 基础 ， 其 目标 是 对 计算 资源 进行 整合 或 
划分 ， 这 是 云 计 算 管 理 平 台中 的 关键 技术 。 虚 拟 化 技术 为 云 计 算 管 理 平 
台 的 资源 管理 提供 了 资源 调配 上 的 灵活 性 ， 从 而 使 得 云 计算 管理 平台 可 
以 通过 虚拟 化 层 整 合 或 划分 计算 资源 。 


相 比 于 虚拟 机 ， 新 出 现 的 容器 技术 使 用 了 一 系列 的 系统 级 别 的 机 
制 ， 诸 如 利用 Linux Namespace 进 行 空间 隔离 ， 通 过 文件 系统 的 挂 载 点 
决定 容器 可 以 访问 哪些 文件 ， 通 过 Cgroup 确 定 每 个 容器 可 以 利用 多 少 资 
源 。 此 外 ， 容 右 之 间 共 享 同一 个 系统 内 核 ， 这 样 当 同 一 个 内 核 被 多 个 容 
右 使 用 时 ， 内 存 的 使 用 效率 会 得 到 提升 。 


容 载 和 虚拟 机 两 大 虚拟 化 技术 ， 虽 然 实现 方式 完全 不 同 ， 但 是 它们 
的 资源 需求 和 模型 其 实 是 类 似 的 。 容 融 像 虚拟 机 一 样 需要 内 存 、CPU、 
硬盘 僧 间 和 网 络 市 宽 ， 和 宿主 机 系统 可 以 将 虚拟 机 和 容 郁 都 视 作 一 个 整 
体 ， 为 这 个 整体 分 配 其 所 需 的 资源 ， 并 进行 管理 。 当 然 ， 虚拟 机 提供 了 


专用 操作 系统 的 安全 性 和 更 牢固 的 逻辑 边界 ， 而 容器 在 资源 边界 上 比较 
松散 ， 这 市 来 了 灵活 性 以 及 不 确定 性 。 


Kubernetes 是 一 个 容器 集群 管理 平台 ，Kubernetes 需 要 统计 整体 平台 
的 资源 使 用 情况 ， 合 理 地 将 资源 分 配给 容器 使 用 ， 并 且 要 保证 容器 生命 
周期 内 有 足够 的 资源 来 保证 其 运行 。 更 进一步 ， 如 果 资 源 发 放 是 独占 
的 ， 即 资源 已 发 放 给 了 一 个 容 右 ， 同 样 的 资源 不 会 发 放 给 男 外 一 个 容 
器 ， 对 于 空 内 的 容器 来 说 占用 着 没有 使 用 的 资源 (比如 CPU) 是 非常 浪 
费 的 ，Kubernetes 需 要 考虑 如 何在 优先 度 和 公平 性 的 前 提 下 提高 资源 的 
利用 率 。 


11.2 资 源 请 求 和 限制 


计算 资源 是 Pod 或 者 容器 运行 所 需 的 ， 包 括 : 


* CPU 
单位 是 核 (core) 


cpu: 1 #1 核 
cpu: 0.25 #0.25 核 
cpu: 250m #0.25 核 


memory: 1024 #1024 Byte 
memory: 512Ki #512 KByte 


memory: 256Mi #256 MByte 


memory: 1.5Gi #1.5 GByte 


创建 Pod 的 时 候 ， 可 以 指定 每 个 容器 的 资源 请 求 (Request) 和 资源 
限制 (Limit) ， 资 源 请 求 是 容器 所 需 的 最 小 资源 需求 ， 资 源 限 制 则 是 
容 右 不 能 超过 的 资源 上 限 ， 它 们 的 大 小 关系 必须 古 : 


0 <= request <= limit <= Infinity 


在 容 絮 的 定义 中 ， 资 源 请 求 通过 resources.requests 设 置 ， 资 源 限制 
通过 resources.limits 设 置 ， 目 前 可 以 指定 的 资源 类 型 只 有 CPU 和 内 存 。 
资源 请 求 和 限制 是 可 选 配置 ， 默 认 值 根据 是 否 设置 Limit Range 而 定 。 如 

资源 请 求 没 有 指定 也 没有 默认 值 ， 那 么 资源 请 求 就 等 于 资源 限制 。 


以 下 定义 的 Pod 包 含 两 个 容器 : 第 一 个 容器 的 资源 请 求 是 0.5 核 CPU 
和 256 MByte 内 存 ， 资 源 限制 是 1 核 CPPU 和 512 MByte 内 存 ; 第 二 个 容器 
的 资源 请 求 是 0.25 核 CPU 和 128MByte 内 存 ， 资 源 限制 是 1 核 CPU 和 512 
MByte 内 存 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: frontend 
spec: 
containers: 
- name: db 
image: mysql 
resources: 


requests: 


memory: "256Mi" 
cpu: "500m" 
limits: 
memory: "512Mi" 
cpu: "1000m" 
- name: wp 
image: wordpress 
resources: 
requests: 
memory: "128Mi" 
cpu: "250m" 
limits: 
memory: "512Mi" 


cpu: "1000m" 


Pod St Ua SE SK/BR fil Ze Pod H PUE Aas SE URGBOK/BR IRA, EEK 
Pod 的 资源 请 求 是 0.75 核 CPU 和 384MByte 内 存 ， 资 源 限制 是 2 核 CPU 和 
1024MByte f£ ° 


Kubernetes 在 调度 Pod 的 时 候 ，Pod 的 资源 请 求 是 调度 的 一 个 关键 指 
标 。Kubernetes 会 获取 Kubernetes Node 的 最 大 资源 容量 (通过 cAdvisor 
BEL) ， 并 计算 出 已 使 用 的 资源 情况 ， 比 如 Node 能 够 容纳 2 核 CPI 和 
2GByte 内 存 ，Node 上 已 经 运作 了 4 个 Pod， 共 请 求 1.5 核 CPU 和 1GByte 内 
存 ， 剩 余 0.5 核 CPU 和 1GByte 内 存 。Kubernetes Scheduler 调 度 Pod 的 时 候 
会 检查 Node 上 是 否 还 有 足够 资源 来 满足 Pod 的 资源 请 求 ， 不 满足 则 将 该 
Node 排 除 。 


将 源 请 求 能 够 保证 Pod 有 足够 的 资源 来 运行 ， 而 资源 限制 则 是 防止 
某 个 Pod 无 限制 地 使 用 资产， 导致 其 他 Pod 表 总 。 特 别 是 在 公有 云 场景 ， 
往往 会 有 恶意 软件 通过 抢占 内 存 来 攻击 平台 。 


ZxHH EH 


Docker 容 器 是 使 用 Linux Cgroup 来 实现 资源 限制 的 ，docker run 就 提 
供 了 参数 对 CPU 和 内 存 进行 限制 。 


* --memory 


docker run 通 过 --memory 给 一 个 容器 可 用 的 内 存 配 额 ，Cgroup 
会 限制 容器 的 内 存 使 用 ， 一 旦 超过 配额 ， 容 如 将 会 被 终止 。 


Kubernetes H? Docker X gë 85] --memory {É Wi 7 resources. limits. memory 
的 值 FE Ul resources.limits.nemory-512Mi , 3 A --memory FH f& Sl. Œ 
512*1024*1024*1024 ° 


* --cpu-shares 


docker run 通 过 --cpu-shares 设 置 一 个 容器 的 可 用 的 CPU 配额 。 
需要 特别 注意 的 是 ， 这 是 一 个 相对 权重 ， 与 实际 的 处 理 速 度 无 关 。 
每 个 新 的 容器 默认 将 有 1024 CPU 配额 ， 当 我 们 单独 讲 它 的 时 候 ， 
这 个 值 并 不 意味 着 什么 。 但 是 如 果 启 动 两 个 容器 并 且 两 个 都 将 使 用 
100% 的 CPU，CPU 时 间 将 在 这 两 个 容 需 之 间 平 均 分 割 ， 因 为 它们 
两 个 都 有 同样 的 CPU 配额 。 如 果 我 们 设置 容器 的 CPU 配额 是 512， 
相对 于 另外 一 个 1024 CPU 配额 容器 ， 它 将 使 用 /3 的 CPU 时 间 。 但 
这 不 意味 着 它 仅 仅 能 使 用 3 的 CPU 时 间 。 如 果 另 外 一 个 容器 
(1024 CPU 配额 的 ) 是 空 亲 的 ， 其 他 容器 将 被 允许 使 用 100% 
CPU“。 对 于 CPU 来 说 ， 难 以 清楚 地 说 明 多 少 CPU 被 分 配给 了 哪个 容 
器 ， 这 取决 于 实际 的 运行 情况 。 


Kubernetes 7 Docker %& 28 [1 --cpu-shares {É ii X} resources.requests.cpu 
或 者 resources. requests.cpu F LÀ 1024 而 得 。 W R 18 Æ 
resources.requests.cpu, #5 A--cpu-shares ji, T resources.requests.cpu?fé LA 
1024, p 4E x5 48 © resources.requests.cpu, {E < 18 4E T resources. 
limits.cpu, 3544 --cpu-shares Wi S T resources.limits.cpu #€ 241024, W 
resources.limits.cpu 和 resources.limits.cpu #5 7x / $8 5E , Hb A 
resources.resources.cpusL bU ]VÉE. (当前 版 本 最 小 值 为 2) ， 具 体 如 下 : 


if resources.requests.cpu is definded 
cpuShares=resources.requests.cpu * 1024 
else if resources.requests.cpu is undefined 
if resources.limits.cpu is defined 
cpuShares-resources.limits.cpu * 1024 
else if resources.limits.cpu is defined 


cpuShares - minShares 


比 如 resources.requests.cpu=250m , B “ --cpu-share 的 值 就 是 
250m*1024=256 ° 


11.3 Limit Range 


Limit Range 设 计 的 初 袁 是 为 了 满足 以 下 场景 : 
。 能 够 约束 租户 的 资源 需求 。 
。 能 够 约束 容器 的 资源 请 求 范 围 。 


“能够 约束 Pod 的 资源 请 求 范围 。 


“ HEUS TRAE Tong HIA VA Ce Ril o 
“ 能 够 指定 Pod 的 默认 资源 限制 。 
© 能 够 约束 资源 请 求 和 限制 之 间 的 比例 。 


提示 


Kubernetes 要 开启 Limit Range 功 能 ， 首 先 要 添加 Limit Range 
Admission Controller， 即 设置 Kubernetes API Server 的 启动 参数 : 


--admission_control=...LimitRange... 


Limit Range 包 含 两 种 类 型 的 设置 ， Container 和 Pod， 包 含 约束 和 默 
认 值 的 配置 ， 如 表 11-1 和 表 11-2 所 示 。 


#211-1 Limit Range Container 配 置 


类 Container 
型 

资 

源 memory 
类 | cpu 

型 


约 | min: min <= Request (required) <= Limit (optional) 


R max: Limit (required) <= max 


maxLimitRequestRatio: maxLimitRequestRatio <= ( Limit 


(required,non-zero) / Request (required,non-zero) 


default: Limit 的 默认 值 
defaultRequest: Request 的 默认 值 


my = £X 


#211-2 Limit Range Pod 配 置 


memory 


cpu 


min: min <= Request (required) <= Limit (optional) 


约 max: Limit (required) <= max 

R maxLimitRequestRatio: (Limit (required,non-zero) / Request 
(required,non-zero) maxLimitRequestRatio 

默 

认 | Pod 的 默认 值 无 须 直 接 配 置 ， 根 据 容 器 的 默认 值 而 得 

值 


创建 Limit Range 的 时 候 需要 注意 以 下 几 点 。 


“ 配置 数值 的 时 候 需 要 满足 以 下 条 件 


Min (if specified) <= DefaultRequest (if specified) <= Default 


(if specified) <= Max (if specified) 


. 默认 值 行为 


当 Default 未 设置 : 


if LimitRangeItem.Default[resourceName] is undefined 
if LimitRangeItem.Max[resourceName] is defined 
LimitRangeltem.Default[resourceName] - 


LimitRangeItem.Max[resourceName ] 


当 DefaultRequest 未 设置 : 


if LimitRangeItem.DefaultRequest[resourceName] is undefined 


if LimitRangeItem.Default[resourceName] is defined 


LimitRangeltem.DefaultRequest[resourceName] 
LimitRangeItem.Default[resourceName | 


else if LimitRangeItem.Min[resourceName] is defined 


LimitRangeltem.DefaultRequest[resourceName] 


LimitRangeItem.Min[resourceName ] 


“4 J£ Namespace F 8l Limit Range 后 ， 就 可 以 设置 Pod 或 者 容 才 的 
资源 请 求 和 限制 默认 值 ， 更 重要 的 功能 是 对 Pod 和 容器 的 资源 规格 配置 


进行 约束 。 现 在 我 们 在 Namespace development P 8/£& — T Limit Range, 
Limit Range 的 定义 文件 limits.yaml: 


apiVersion: vi 
kind: LimitRange 
metadata: 

name: limits 


namespace: development 


spec: 
limits: 
- type: Pod 
max: 
cpu: 4 
memory: 2Gi 
min: 


cpu: 250m 
memory: 8Mi 
maxLimitRequestRatio: 
cpu: 4 
memory: 4 
- type: Container 
default: 
cpu: 500m 
memory: 512Mi 
defaultRequest: 
cpu: 250m 


memory: 256Mi 


max: 
cpu: 2 
memory: 1Gi 
min: 
cpu: 250m 
memory: 8Mi 
maxLimitRequestRatio: 
cpu: 2 


memory: 2 


通过 定义 文件 创建 Limit Range: 


$ kubectl create -f limits.yaml 


limitrange "limits" created 


创建 成 功 ， 查 询 Limit Range: 


$ kubectl describe limitranges limits --namespace=development 
Name: limits 
Namespace: development 


Type Resource Min Max Request Limit Limit/Request 


Pod cpu 250m 4 - - 4 

Pod memory  8Mi 26i - - 4 

Container cpu 250m 2 250m 500m 2 
Container memory  8Mi 16i 256Mi 512Mi 2 


对 于 以 上 内 容 有 以 下 几 点 说 明 o 


。 默认 值 

1. 一 个 容器 的 默认 资源 请 求 是 256Mbyte 内 存 和 250m 核 CPU 。 
2. 一 个 容器 的 默认 资源 限制 是 512Mbyte 内 存 和 500m 核 CPU。 
。 约束 

1. 一 个 Pod 的 资源 请 求 和 限制 必须 满足 : 


250m <= requests.cpu <= limits.cpu <= 4 
8Mi <= requests.memory <= limits.memory <= 2Gi 
limits.memory/requests.memory <= 4 


limits.cpu/requests.cpu <= 4 


2. “Se i EO] EEG CAT BRR ll YB: 


250m <= requests.cpu <= limits.cpu <= 2 
8Mi <= requests.memory <= limits.memory <= 1Gi 
limits.memory/requests.memory <= 2 


limits.cpu/requests.cpu <= 2 


至 此 ， 在 Namespace development 中 创建 的 Pod 都 需要 满足 以 上 约 
束 ， 比 如 创建 一 个 Pod，Pod 的 定义 文件 test-pod.yaml: 


apiVersion: v1 

kind: Pod 

metadata: 
name: test 


namespace: development 


spec: 
containers: 

- name: container1i 
image: nginx 
resources: 

requests: 
memory: 512Mi 
cpu: "999m" 
limits: 
memory: "512Mi" 
cpu: "2" 

- name: container2 
image: nginx 
resources: 

requests: 
memory: 512Mi 
cpu: "250m" 
limits: 
memory: "1Gi" 
cpu: "500m" 

- name: container3 
image: nginx 
resources: 

requests: 
memory: 8ki 
cpu: "250m" 


limits: 


memory: "1Gi" 


cpu: "500m" 


创建 Pod 会 失败 : 


$ kubectl create -f test-pod.yaml 

Error from server: error when creating "test-pod.yaml": Pod 
"test" is forbidden: [ 

Maximum memory usage per Pod is 2Gi, but limit is 2684354560., 
cpu max limit to request ratio per Container is 2, but provided 
ratio is 2.002002., 

Minimum memory usage per Container is 8Mi, but request is 8Ki., 
memory max limit to request ratio per Container is 2, but 


provided ratio is 131072.000000. | 


其 中 有 4 个 错误 : 


1. Pod 的 最 大 内 存 为 2Gi， 但 是 创建 的 Pod 资 源 限 制 是 
1Gi*1Gi*512Mi-2684354560 ° 


2. 容器 的 CPU 限 制 和 请 求 比例 不 能 超过 2， 容 器 container1 的 CPU 限 
制 和 请 求 比 例 为 2/0999m=2.002002 ° 


3. 容器 的 最 小 内 存 是 8mi， 容 器 container3 的 CPU 请 求 是 8Ki ° 
4. 容器 的 内 存 限 制 和 请 求 比例 不 能 超过 2， 容 器 container3 的 内 存 限 


制 和 请 求 比例 为 500m /8ki =131072.000000 ° 


11.4 Resource Quota 


Kubernetes 是 一 个 多 租户 架构 ， 当 多 用 户 或 者 团队 共享 一 个 
Kubernetes 系 统 的 时 候 ， 系 统管 理 员 需要 防止 租户 的 资源 强占 ， 定 义 好 
资源 分 配 策略 。 比 如 Kubemetes 系 统 共有 20 核 CPU 和 32GByte 内 存 ， 分 配 
给 A 租户 5 核 CPU 和 16 GByte， 分 配给 B 租 户 5 核 CPU 和 8GByte， 预 留 10 
核 CPU 和 8GByte 内 存 。 这 样 ， 租 户 中 所 使 用 的 CPU 和 内 存 的 总 和 不 能 超 
过 指定 的 资源 配额 ， 促 使 其 更 合理 地 使 用 资源 。 


Kubernetes 中 提供 API 对 象 Resource Quota 《资源 配额 ) 来 实现 资源 
ACAN, Resource Quota 不 仅 可 以 作用 于 CPU 和 内 存 ， 另 外 还 可 以 限制 比 
如 创建 Pod 的 数目 。Resource Quota 支 持 的 类 型 如 表 11-3 和 表 11-4 所 示 。 


* 计算 资源 配额 


表 11-3 ”计算 资源 配额 


资源 名 称 说 明 
cpu CPUACAI 
memory 内 存 配额 


限制 计算 资源 的 使 用 ，Namespace 中 所 有 Pod 的 资源 请 求 总 和 不 能 超 
过 配额 ， 比 如 Namespace A 的 内 存 配额 为 1GByte， 那 么 Namespace A 中 
所 有 Pod 的 Memory 请 求 总 和 ， 即 resources.reqdquests.memory 的 总 和 不 能 超 
过 1GByte。 


。Kubernetes API 对 象 资源 配额 


3211-4  Kubernetes API 对 象 资 源 配额 


资源 名 称 说 明 
pods Pod 的 总 数目 


Services Service 的 总 数 


replicationcontrollers Replication Controller 的 总 数 


resourcequotas Resource Quota 的 总 数目 
Secrets Secret 的 总 数目 


persistentvolumeclaims Persistent Volume Claim 的 总 数 


限制 Kubernetes API 对 象 的 创建 数目 ，Namespace 中 API 对 象 的 创建 
数目 不 能 超过 配额 ， 比 如 限制 Namespace A 的 Pod 和 Service 的 创建 数目 。 


提示 


Kubernetes 要 开启 Resource Quota 支持 ， 首 先 要 添加 Resource 


Quota Admission Controller, ， 即 设置 Kubernetes API Server 的 启动 参 
Z: 


--admission_control=...ResourceQuota... 


默认 情况 下 ，Namespace 是 没有 Resource Quota 的 ， 需 要 另外 创建 
Resource Quota。 一 般 情 况 下 ， 一 个 Namespace 下 配置 一 个 Resource 
Quota 即 可 ， 但 是 可 以 创建 多 个 Resource Quota ， 将 按 多 个 Resource 
Quota 最 小 值 作为 配额 值 。 比 如 一 个 Resource Quota 设 置 Pod 的 数目 配额 
为 10， 男 一 个 Resource Quota 设 置 Pod 的 数目 配额 为 5， 那 么 Pod 的 数目 不 
能 超过 5.。 


现在 我 们 在 Namespace development 下 创建 一 个 Resource Quota , 
Resource Quota 的 定义 文件 quota.yaml: 


apiVersion: v1 
kind: ResourceQuota 
metadata: 
name: quota 
namespace: development 
spec: 
hard: 
cpu: "20" 
memory: 50Gi 
persistentvolumeclaims: "10" 
pods: "10" 
replicationcontrollers: "20" 
resourcequotas: "1" 
secrets: "10" 


services: "5" 


通过 定义 文件 创建 Resource Quota: 


$ kubectl create -f quota.yaml 


resourcequota "quota" created 


创建 成 功 后 可 以 查询 Resource Quota， 其 中 包括 配额 值 和 使 用 值 : 


$ kubectl describe resourcequota quota --namespace=development 


Name : quota 
Namespace: development 
Resource Used Hard 


memory 0 1Gi 
persistentvolumeclaims O 10 
pods © 10 
replicationcontrollers 0 20 
resourcequotas 1 1 

secrets 1 10 


services 0 5 


— E Namespace f Resource Quota， 创 建 Pod 的 时 候 就 必须 指定 资源 
请 求 ， 否 则 Pod 会 创建 失败 (Kubernetes 返 回 403 FORBIDDEN) ° 同样 
的 ，Pod 请 求 的 资源 超过 了 资源 配额 也 会 创建 失败 (Kubemetes 将 返回 
403 FORBIDDEN) 。 


现在 在 Namespace development 下 创建 一 个 Pod， 请 求 0.25 核 CPU 和 
128MByte 的 内 存 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: nginx 
namespace: development 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 


protocol: TCP 


resources: 
requests: 
memory: "128Mi" 
cpu: "250m" 
limits: 
memory: "512Mi" 


cpu: "500m" 


在 Pod 创 建成 功 后 ， 可 以 查询 到 相应 的 资源 使 用 情况 ， 共 消耗 1 个 


Pod， 以 及 0.25 核 CPU 和 128MByte 的 内 存 : 


$ kubectl describe resourcequota quota --namespace=development 


Name: quota 

Namespace: development 
Resource Used Hard 
cpu 250m 20 

memory 134217728 1Gi 


persistentvolumeclaims 0 10 
pods 1 10 
replicationcontrollers 0 20 
resourcequotas 1 1 

secrets 1 10 


services 0 5 


第 12 章 
管理 和 运 维 Kubernetes 


Kubernetes 回 下 接管 底层 资源 ， 癌 上 托管 业务 应 用 ， 要 管理 和 运 
维 这 样 一 父系 统 可 以 说 是 一 个 巨大 的 挑战 。 笠 运 的 是 ，Kubernetes 已 
经 提供 了 一 些 很 好 的 文 持 来 帮助 管理 Kubernetes。 本 章 将 介绍 


Kubemetes 的 高 可 靠 性 方案 、 平 台 监 控 、 平 台 日 志 等 。 


12.1 Daemon Pod 


ARG BRAY Fe KKM, RITE 3$ m TE KubernetesH Pr T A 
上 运行 一 些 守 护 进 程 (Daemon) ， 比 如 日 志 收 集 、 监 控 等 。 传 统 的 做 
法 是 使 用 一 些 Imit 工 具 (比如 init、upstartd， 或 者 systemd) 来 进行 管 
理 ， 而 Kubernetes 中 文 持 以 Pod 的 形式 运行 这 些 守 护 进程 ， 我 们 称 为 
Daemon Pod， 实 现 的 方式 包括 Static Pod 和 Daemon Set ° 


12.1.1 Static Pod 


Static Pod z& Ei £ EH Kubelet 4H f 8] @ ` 34 íT Æ Node E HY Pod, 
Kubelet2H fF fi it Static Pod 的 持续 运行 ， 而 无 须 Replication Controlleri# 
行 关 联 管理 。 这 样 一 来 ，Static Pod 束 同 Kubelet 进 行 绑 定 ， 从 而 运行 在 
Node 上 作为 Daemon Pod ° 


Static Pod 的 创建 是 通过 在 Kubelet 指 定 的 Manifest 目 录 中 放 入 Pod 的 
定义 文件 (JSON 或 者 YAML 格 式 ) 进行 的 ，Manifest 目 录 是 通过 
Kubelet 的 局 动 参数 --config 配 置 的 。 本 书 Kubernetes 运 行 环境 指定 
KubeletH‘/Manifest H 3K 7j/etc/kubernetes/manifests ° 


现在 通过 Static Pod T£ Kubernetes Node E3247 Prometheus, —^ F 
源 的 服务 监控 系统 ， 可 以 实现 对 Docker 容 器 进行 监控 。 这 需要 在 所 有 
Node 上 的 Manifest 目 录 中 创建 Static Pod 的 定义 文件 prometheus-node- 


exporter.yaml: 


apiVersion: vi 
kind: Pod 
metadata: 
name: prometheus-node-exporter 
labels: 
daemon: prom-node-exp 
spec: 
containers: 
- name: c 
image: prom/prometheus 
ports: 
- name: serverport 
containerPort: 9090 


hostPort: 9090 


Kubelet 将 在 Node 上 运行 Static Pod, &E ¥ Static Pod 的 名 称 是 Pod 和 名 
称 拼接 上 Node 的 名 称 : [pod_name]-[node_name]: 


$ kubectl get pod --selector daemon=prom-node-exp --output wide 


NAME READY STATUS 
RESTARTS AGE NODE 

prometheus-node-exporter -kube-node-1 1/1 Running 0 
15s kube-node-1 

prometheus -node-exporter - kube-node-2 1/1 Running 0 
18s kube-node-2 

prometheus -node-exporter - kube-node-3 1/1 Running 0 
25s kube-node-3 


如 果 删 除 该 Static Pod，Kubelet 会 重新 创建 Static Pod， 保 证 其 持续 
Aft, mu H8 Manifest H 5 + Ml PRIX Static Pod 的 定义 文件 ，Static 
Pod 才 会 被 删除 。 


除了 直接 在 Manifest 目 隶 中 放 入 Static Pod 定 义 文 件 ， 还 可 以 通过 
Kubelet 的 局 动 参数 --manifest-url=<URL> 指 定 远程 URL Kubelet A Æ 
期 下 载 Static Pod 的 定义 文件 进行 创建 或 者 更 新 。 


使 用 Static Pod 能 够 运行 Daemon Pod， 但 是 Static Pod 的 管理 是 比较 
低 效 的 。 比 如 发 生变 更 ， 残 可 能 需要 修改 每 个 Node 上 的 Kubelet 配 置 。 
为 此 ，Kubernetes 提 供 了 一 个 更 加 强大 的 机 制 来 管理 运行 Daemon 
Pod ° 


12.1.2 Daemon Set 


Kubernetes#a:{# T Daemon Set， 用 来 在 Kubernetes Node 上 创建 运行 
Daemon Pod ° Daemon Set 的 作用 同 Replication Controller 类 似 ， 它 们 都 


是 管理 控制 Pod 的 ， 只 不 过 Daemon Set 是 保证 所 有 (或 者 部 分 ) Node 
上 都 能 够 运行 Daemon Pod ° 


在 当前 版 本 (Kubernetes v1.1.1) 中 ，Daemon Set 是 Beta 测试 


阶段 ， 需 要 设置 Kubernetes API Server 启动 参数 --runtime- 


config=extensions/vlbetal/daemonsets=true 来 开启 Daemon Set x $$ ° 


现在 通过 Daemon Set 在 Kubernetes Node 上 运行 Prometheus , 
Daemon Set 的 定义 文件 prometheus-node-exporter.yaml: 


apiVersion: extensions/vibetai 
kind: DaemonSet 
metadata: 
name: prometheus-node-exporter 
spec: 
template: 
metadata: 
labels: 
daemon: prom-node-exp 
spec: 
containers: 
- name: c 


image: prom/prometheus 


ports: 
- name: serverport 
containerPort: 9090 


hostPort: 9090 


可 以 看 出 ，Daemon Seth) XE X. Al Replication Controller - 1, 3B 
过 .spec.template 设 置 Pod 的 模板 。 因 为 Daemon Pod 需 要 持续 运行 ， 所 以 
Pod 的 模板 中 的 重启 集 略 只 能 是 Always。 


在 默认 情况 下 ，Daemon Set 会 在 所 有 Node 上 运行 Daemon Pod, ii 
iw .spec.template.spec. nodeSelector 设 置 Node Selector， 可 以 只 在 匹配 的 
Node 上 运行 Daemon Pod ° 


通过 定义 文件 创建 Daemon Set: 


$ kubect1 create -f prometheus -node-exporter.yaml -- 
validate=false 


daemonset "prometheus-node-exporter" created 


$ kubectl get daemonset prometheus-node-exporter 


NAME CONTAINER(S) IMAGE(S) 
SELECTOR NODE-SELECTOR 
prometheus-node-exporter e prom/prometheus 


daemon=prom-node-exp <none> 


Daemon Set 创 建成 功 后 ， 将 在 所 有 Node 上 运行 Pod: 


$ kubectl get pods --selector daemon=prom-node-exp --output 


wide 


NAME READY STATUS 


RESTARTS AGE NODE 

prometheus-node-exporter-qpta1 1/1 Running 0 
50s kube-node-1 

prometheus-node-exporter-j04ks 1/1 Running 0 
50s kube-node-2 

prometheus-node-exporter-ss23x 1/1 Running 0 
50s kube-node-3 


当 删 除 Daemon Set 后 ， 相 关联 的 Pod 也 会 被 删除 


$ kubectl delete daemonset  prometheus-node-exporter 


daemonset "prometheus-node-exporter" deleted 


$ kubectl get pods --selector daemon-prom-node-exp -o wide 


NAME READY STATUS RESTARTS AGE NODE 


如 果 希 望 删除 Daemon Set 而 保留 关联 的 Pod， 运 行 kubectl delete 时 
加 上 参数 --cascade=false 即 可 。 


12.2 ”Kubernetes 的 高 可 用 性 


高 可 用 性 是 一 个 老生 常 谈 的 话题 ， 当 然 是 因为 这 是 人 们 非常 关心 
的 特性 ， 它 决定 了 一 个 系统 的 最 终 价值 。 akan 任何 系统 都 
需要 持续 可 靠 地 运行 ， 保 持 其 服务 的 高 度 可 用 性 ， 这 是 一 个 最 基本 的 
要 求 。 特 别 是 对 于 Kubemetes 这 样 的 云 平 台 ， i ee 


用 的 系统 ， 它 的 任何 故障 都 可 能 大 面积 地 影响 业务 ， 甚 重要 性 目 然 不 


言 而 喻 。 


Kubernetes 必 于 典型 的 主 从 分 布 式 架构 ，Kubernetes 的 重要 数据 集 
中 存储 在 Etcd， 数 据 层 的 可 靠 性 至 关 重 要 ， 对 Etcd 进 行 集 群 化 是 必 不 
可 少 的 〈 可 参考 14.3.2 节 ) ° 


Kubernetes Node 作 为 Pod 的 运行 机 ， 原 生 文 持 集 群 化 扩展 来 提供 容 
灾 容 错 能 力 。Kubernetes Node 运 行 后 将 会 注册 到 Kubernetes Master, 
并 定时 上 报 心 跳 信 息 以 说 明 其 可 用 。Kubernetes Master 调 度 Pod 到 可 用 
的 Kubernetes Node 部 署 运 行 ， 如 果 有 Kubernetes Node 发 生 宕 机 ， 
Kubernetes Master 会 将 该 Kubernetes Node 设 置 为 不 可 用 状态 。 然 后 
Replication Controller 会 重新 创建 Pod， 从 而 调度 到 新 的 Kubernetes Node 
上 。 当 然 ，Kubernetes Node 的 数目 至 少 要 大 于 2 才 可 以 保障 Pod 的 高 可 
用 性 。 


在 Kubernetes Master 的 高 可 用 性 方案 中 需要 特别 注意 ，Kubernetes 
API Server 可 以 多 实例 运行 ， 而 Kubernetes Scheduler 和 Kubernetes 
Controller Manager 不 能 有 多 个 实例 同时 运行 。Kubernetes 官 方 提供 了 一 
种 方案 ， 如 图 12-1 所 示 。 
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图 12-1 Kubernetes 的 高 可 用 性 


在 这 个 方案 中 ，Kubernetes Master 多 节点 部 署 ， 其 中 Kubernetes 
API Server ` Kubernetes Scheduler 和 Kubernetes Controller Manager 3 个 
组 件 分 别 作为 Static Pod 由 Kubelet 来 控制 管理 。Kubernetes API Servern] 
以 在 每 个 Kubernetes Master 玉 点 上 运行 ， 前 问 通 过 负载 均衡 器 作为 访 
HAO ° 


Fy 5, ^" Kubernetes Master 点 上 需要 运行 一 个 小 程序 
Podmaster, ，Podmaster 通 过 Etcd 进 行 选 举 ， 从 多 个 Kubernetes Master 
选择 主 丰 点， 只 有 主 和 点 上 会 运行 Kubernetes Scheduler 和 Kubernetes 
Controller Manager ° SEP RARE AVN, eR NED RIB 


Kubernetes Scheduler 和 Kubernetes Controller Manager ° 


12.3 平台 监控 


监控 是 整个 运 维 环节 ， 力 至 整个 产品 生命 周期 中 最 重要 的 一 环 ， 
事前 及 时 预警 发 现 故障 ， 事 后 提供 翔实 的 数据 用 于 追查 定位 问题 。 对 
于 Kubermetes 来 说 ， 监 控 的 层级 和 需求 是 多 样 的 ， 对 于 系统 管理 员 来 
说 ， 硕 望 Kubernetes 系 统 级 别 的 监控 ， 比 如 Node 的 资源 消耗 数据 用 来 
判断 是 否 需要 增加 新 的 机 器 。 而 对 于 使 用 人 员 来 说 ， 和 希望 应 用 本 喘 监 
控 ， 包 括 Pod 或 者 容 需 的 详细 运行 数据 ， 用 以 了 解 应 用 的 性 能 情况 和 
HLM TE ° 


Kubermeteste tt T FE Maux dw, BRAEDS 423.27, WE 
Kubernetes 各 个 维度 的 数据 ，Kubernetes 平 台 监控 的 逻辑 设计 如 图 12-2 
所 示 。 


图 12-2 KubernetesYÉ & I$ 


Kubernetes 平 台 监 控 的 两 个 关键 组 件 是 cAdvisor 和 Heapster ° 


12.3.1 cAdvisor 


cAdvisor (Container Advisor) 是 谷歌 开源 的 一 个 容器 监控 工具 。 
它 是 一 个 守护 进程 ， 收 集 、 统 计 和 处 理 宿主 机 和 容器 的 数据 ， 包 括 实 
时 和 历史 的 CPU、 内 存 、 人 磁盘 、 网 络 使 用 情况 。 同 时 ，cAdvisor 提 供 
民 好 的 Web 界 面 和 Rest API 来 展示 数据 ， 帮 助 系统 管理 者 清楚 了 解 容 器 
的 资源 使 用 情况 和 运行 性 能 数据 。 


提示 


在 cAdvisor 的 认识 中 ， 容 大 的 概念 是 广义 的 ， 不 仅仅 包括 


Docker 容 器 ， 也 包括 其 他 容器 实现 ， 另 外 宿主 机 本 身 也 是 一 种 容 
器 ， 称 为 根 容器 ， 它 是 一 种 原生 容器 。 


Web UI 


cAdvisor 提 供 了 一 个 Web 界 面 可 以 查询 监控 数据 ， 在 cAdvisor 运 行 
后 ， 便 可 以 访问 cAdvisor 的 Web 界 面 ， 如 图 12-3 所 示 。 
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Total Usage 


9:54:20 PM 9:54:30 PM 9:54:40 PM 9:54:50 PM 9:55:00 PM 9:55:10 PM 
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图 12-3 cAdvisor Web X Mi 
REST API 


cAdvisor 提 供 REST API 用 于 获取 监控 数据 ，cAdvisor 的 REST API 
访问 方式 为 http:/ <hostname>:<port>/api/<version>/<request> ° 


cAdvisor REST API 文 持 的 版 本 和 请 求 类 型 如 下 所 示 。 
* v1.0: containers,machine 

e v1.1: containers,machine,subcontainers 

* v1.2: containers,docker,machine,subcontainers 


* v1.3: containers,docker,events,machine,subcontainers 


^ v2.0 


appmetrics,attributes,events,machine,ps,spec,stats,storage,summary,version 


其 中 v1.3 是 最 新 的 稳定 版 本 ，v2.0 处 于 beta 阶 段 ， 具 体 说 明 如 表 12- 
1 所 示 。 


3212-1 cAdvisor REST API 


GET /api/v1.x/machine 获取 宿主 机 信息 

GET /api/v1.x/containers/<container> 获取 指定 容器 的 监控 数据 

GET /api/v1.x/subcontainers/<container> | 获取 指定 子 容器 的 监控 数据 

GET /api/v1.x/docker 获取 所 有 Docker 容 器 的 监控 

GET /api/v1.x/docker/<container> 获取 指定 Docker 容 器 的 监控 数据 。 可 以 使 用 Docker 
容器 UUID 或 者 名 称 

GET /api/v1.x/events/<container> 获取 指定 容器 的 事件 信息 

GET /api/v2.X/version 获取 cAdvisor 的 版 本 

GET /api/v2.x/machine 获取 宿主 机 信息 

GET /api/v2.x/attributes 获取 宿主 机 的 硬件 和 软件 属性 

GET /api/v2.x/storage 获取 宿主 机 的 存储 设备 信息 

GET /api/v2.x/stats/<container> 获取 指定 容器 的 统计 数据 。 Docker 容 器 需要 增加 参数 
type=docker 

GET /api/v2.x/summary/<container> 获取 指定 容器 的 统计 汇总 数据 。 Docker 容 器 需要 增加 
参数 type=docker 

GET /api/v2.x/spec/<container> 获取 指定 容器 的 规格 。Docker 容 器 需要 增加 参数 
type=docker 

GET /api/v2.x/ps/<container> 获取 指定 容器 包含 的 所 有 进程 信息 。 Docker 容 器 需要 
增加 参数 type=docker 

GET /api/v2.x/appmetrics/<container> 支持 自 定义 应 用 的 监控 维度 ， 通 过 API 获 取 监 控 数 据 


Kubelet 集 成 


Kubelet 组 件 已 经 集成 了 cAdvisor， 在 Kubernetes Node 上 可 以 直接 
访问 cAdvisor，cAdvisor 运 行 端口 可 以 通过 Kubelet 的 启动 参数 -- 
cadvisor-port 设 置 ， 默 认 是 4194。 


Kubelet 基 于 cAdvisor 提 供 了 REST API (默认 端口 10255) 来 获取 
Node 和 Pod/ 容 器 的 监控 数据 。 


e 获取 Node 的 监控 统计 数据 ， 如 表 12-2 所 示 。 


表 12-2 ”获取 Node 的 监控 统计 数据 


URL GET /stats/ 


num stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 
值 为 60 

start: 统计 的 起 始 时 间 ， 默 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 默 认 当 前 时 间 


e 获取 非 Kubemetes 容 磊 的 监控 统计 数据 ， 如 表 12-3 所 示 。 


表 12-3 ”获取 非 Kubernetes 容 器 的 监控 统计 数据 


containerName: 需要 统计 的 容器 名 称 ， 默 认 


EH” 
subcontainers: 是 否 包 含 子 容器 ， 默 认 值 为 
false 
参数 E E 
num stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 
值 为 60 


start: 统计 的 起 始 时 间 ， 移 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 黑 认 当 前 时 间 


。 获 取 Kubernetes 容 器 的 监控 统计 数据 ， 如 表 12-4 所 示 。 


212-4 ”获取 Kubernetes 容 器 的 监控 统计 数据 


GET /stats/<namespace>/<pod_name>/<container_name> 


URL | GET /stats/<pod_name>/<container_name> (查询 默认 


Namespace) 


num, stats: 返回 最 大 的 统计 数据 条 数 ， 默 认 值 为 60 
参数 | start， 统 计 的 起 始 时 间 ， 默 认 最 开始 的 时 间 
end: 统计 的 结束 时 间 ， 默 认 当 前 时 间 


Kubelet 统 计 API 返 回 的 监控 统计 数据 的 格式 如 下 所 示 。 


。namespace: 命名 空间 ， 由 cAdvisor 定 义 。 


。subcontainers: 包含 的 子 容器 列表 。 
espec: 容 絮 规格 ， 包 含 如 下 信息 。 


creation time: 创建 时 间 。 
e labels: 包含 的 标签 。 

*has cpu: 是 否 有 CPU。 
。cpu: CPU 信 息 。 

*has memory: 是 否 有 内 存 。 
e memory: 内 存 信 息 。 

*has network: 是 否 有 网 络 。 


* has filesystem: 是 否 有 文件 系统 。 
*has diskio: iE RAIO 。 
"image: 容器 镜像 。 


stats: 容器 监控 统计 数据 ， 每 条 数据 包含 如 下 信息 。 


e timestamp: HJ [B] ° 

e cpu: CPU 统计 数据 。 

e diskio: 人 磁 一 IO 统计 数据 。 

e memory: 内 存 统计 数据 。 

e network: 网 络 统计 数据 。 

* filesystem: 文件 系统 统计 数据 。 


*task stats: 任务 统计 数据 。 


12.3.2  Heapster 


Heapster 是 谷歌 开源 的 容器 集群 的 监控 收集 工具 ， 它 可 以 集成 
Kubernetes 进 行 监控 数据 的 收集 汇总 ， 提 供 REST API 来 获取 Kubernetes 
各 个 维度 的 监控 数据 。 另 外 ，Heapster 支 持 对 接 第 三 方 系统 ， 将 监控 
数据 导入 到 第 三 方 系统 进行 进一步 处 理 。 


REST API 


Heapsterfe REST API， 如 表 12-5 所 示 。 


表 12-5 Heapster REST API 


类 型 URL 说 明 


metric | GET /api/v1/metric-export 获取 最 新 的 Metric 数 据 
GET /api/v 1/metric-export-schema 获取 Metric 数 据 的 规格 
Sink POST /api/vl/sinks 配置 当前 的 Sink 


GET /api/v l/sinks 获取 当前 的 Sink 


集成 Kubernetes 


Heapster 在 与 Kubernetes 集 成 的 时 候 ，Heapster 调 用 Kubernetes API 
获取 所 有 Node 列 表 ， 然 后 调用 Kubelet 的 API 收 集 汇 总 监控 数据 。 同 
时 ，Heapster 根 据 收集 到 的 数据 建立 一 个 Kubernetes 监 探 模型 (Metric 
Model) ， 包 括 Kubernetes 以 下 层级 。 


* Cluster: 整个 Kubernetes 运 行 环境 的 监控 模型 。 


。Node: 各 个 Node 的 监控 数据 模型 ,包括 机 器 本 身 的 监控 和 Node 
上 运行 的 Pod 的 监控 。 


。Namespace: 各 个 Namespace 监 控 模 型 ， 相 当 于 Namespace 下 所 有 
Pod 的 监控 。。Pod: 各 个 Pod 的 监控 模型 。 


* Container: 各 个 Container 监 控 模 型 。 


Kubernetes 监 探 模型 提供 API 来 获取 各 个 层级 的 监控 数据 ， 如 表 12- 
6 所 示 。 


3212-6 Kubernetes 监控 模型 


层级 URL 
Cluster /api/v1/model/ 


/api/v1/model/metrics/ 


/api/v1/model/metrics/<metric-name> 


/api/v1/model/stats/ 


/api/v1/model/nodes/ 
/api/v1/model/nodes/<node-name>/ 
/api/v1/model/nodes/<node-name>/pods/ 
/api/v1/model/nodes/<node-name>/metrics/ 


/api/v1/model/nodes/<node-name>/metrics/<metric-name> 


/api/v1/model/nodes/<node-name>/stats/ 


续 表 
层级 URL 


Namespace | /api/v1/model/namespaces/ 


/api/v 1/model/namespaces/<namespace-name>/ 


/api/v 1/model/namespaces/<namespace-name>/metrics/ 


/api/v 1/model/namespaces/<namespace-name>/metrics/<metric-name> 


/api/v 1/model/namespaces/<namespace-name>/stats/ 


/api/v 1/model/namespaces/<namespace-name>/pods/ 


/api/v 1/model/namespaces/<namespace-name>/pods/ { pod-name }/ 


/api/v 1/model/namespaces/<namespace-name>/pods/ { pod-name }/metrics/ 


/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/metrics/<metric-name> 


/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/stats/ 


Container /api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/ 


/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 


/api/v 1/model/namespaces/{ namespace-name }/pods/<pod-name>/containers/<container-name>/ 
metrics/ 
/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 


metrics/<metric-name> 


/api/v 1/model/namespaces/<namespace-name>/pods/<pod-name>/containers/<container-name>/ 
stats/ 


/api/v 1/model/nodes/<node-name>/freecontainers/ 


/api/v 1/model/nodes/<node-name>/freecontainers/<container-name>/ 


/api/v 1/model/nodes/<node-name>/freecontainers/<container-name>/metrics/ 


/api/v 1/model/nodes/ { node-name }/freecontainers/{ container-name }/metrics/{ metric-name } 


/api/v 1/model/nodes/{ node-name }/freecontainers/{ container-name }/stats/ 


12.4 平台 日 志 


Kubermetes 提 供 了 平台 日 志文 持 ， 安 狠 方 法 可 参考 2.3.3 人 。 和 平台 
日 志 基 于 Fluentd+ Elasticsearch+Kibana ， 其 中 Fluentd 作 为 Logging 


Agent 收 集 日 志 汇 总 到 Elasticsearch ° 


Fluentd 是 一 个 开源 的 日 志 收 集 系 统 ， 文 持 150 多 个 插件 ， 能 够 将 
日 志 收 集 到 MongoDB、Redis、Amazon S3 和 Elasticsearch 等 ; Fluentd 
能 够 以 JSON 格 式 处 理 日 志 ， 具 备 每 天 收集 5000+ 台 服务 器 上 5TB 的 日 
志 数 据 ， 每 秒 处 理 50000 条 消息 的 性 能 。 


Fluentd 运 行 在 Kubernetes 的 所 有 和 点 上 ， 收 集 Kubernetes 组 件 的 日 
志 ，Fluentd 的 配置 如 下 所 示 : 


<source> 
type tail 
format none 
path /var/log/docker.1og 
pos file /var/log/es-docker.log.pos 
tag docker 


«/source» 


«source» 
type tail 
format none 
path /var/log/etcd.log 
pos file /var/log/es-etcd.log.pos 
tag etcd 


«/source» 


«source» 


type tail 


format none 

path /var/log/kubelet.log 

pos file /var/log/es-kubelet.log.pos 
tag kubelet 


«/source» 


«source» 
type tail 
format none 
path /var/1log/kube-apiserver.log 
pos file /var/log/es-kube-apiserver.log.pos 
tag kube-apiserver 


«/source» 


«source» 
type tail 
format none 
path /var/log/kube-controller-manager.log 
pos file /var/log/es-kube-controller-manager.log.pos 
tag kube-controller-manager 


«/source» 


«source» 
type tail 
format none 
path /var/1log/kube-scheduler.log 
pos file /var/log/es-kube-scheduler.log.pos 


tag kube-scheduler 


</source> 


Fluentd 配 置 中 的 Source 用 于 指定 日 志 输 入 资源 ， 其 中 字段 含义 如 
下 所 示 。 


«type: 指定 日 志 的 输入 方式 ， 其 中 tail 方 式 是 不 停 地 从 源 文件 中 
获取 新 的 日 志 。 


e format: 指定 日 志 的 输出 格式 。 
e path: 指定 日 志文 件 的 位 置 。 


etag: 指定 日 志 tag， 用 来 对 不 同 的 日 志 进 行 分 类 。 


可 以 看 出 ，Fluentd 将 监控 每 个 组 件 的 日 志文 件 ， 然 后 设置 上 tag， 
最 后 输出 。 为 外 ，Fluentd 同 时 会 监控 容 右 的 日 志文 件 : 


<source> 
type tail 
path /var/log/containers/*.log 
pos file /var/log/es-containers.log.pos 
time format 96Y -96m-96d T96H : 96M : 96S 
tag kubernetes.* 
format json 
read from head true 


«/source» 


Fluentd 会 监控 /var/log/containers 目 录 下 的 所 有 日 志文 件 ， 然 后 以 
JSON 格 式 输出 ， 其 中 设置 的 tag 是 kubernetes.* ， 在 tail 方 式 下 会 被 设置 


7: kubernetes.path.to.file ° 


实际 上 ，/var/log/containers 日 ia 由 Kubelet 组 件 创建 的 ，Kubelet 
在 其 中 建立 Pod 的 容器 日 志文 件 ， 这 些 是 容 絮 中 应 用 打印 到 标准 输出 
(Stdout) 的 日 志 ， 即 通过 kubectl logs 或 者 docker logs 查 询 到 的 日 志 。 


比如 我 们 运行 的 Hello World Pod， 其 信息 查询 如 下 : 


$ kubectl describe pod hello-world 
Name: hello-world 

Namespace: default 

Image(s): ubuntu:14.04 

Node: kube-node-2/192.168.3.148 


Start Time: Fri, 04 Dec 2015 19:28:21 +0800 


Labels: <none> 
Status: Succeeded 
Reason: 

Message: 

IP: 


Replication Controllers:<none> 
Containers: 
hello: 


Container ID: 


docker://8c9df43b96227d14f8665d87d5b32ee39ce11328bd1d1848465c3c 
9e97a09b8a 
Image:  ubuntu:14.04 


Image ID: 


docker://8251da35e7a79dca688682f6da6148a06d358c6f094020844468a7 
82842C2172 
State: Terminated 
Reason: Error 
Exit Code: 0 
Started: Fri, 04 Dec 2015 19:28:28 +0800 
Finished: Fri, 04 Dec 2015 19:28:29 +0800 
Ready: False 
Restart Count: O 


Environment Variables: 


Hello World Pod, & HJ — "i abello RE 出 Hello World, ix4&585 
出 日 志 实 际 上 是 由 Docker 进 行 存 储 ， 并 通过 Kubernetes 获 取 的 ， 而 
Fluentd 将 会 进行 日 志 收 集 。 


$ kubectl logs hello-world hello 


Hello World 


Docker #& AF HJ AO B & FH Docker 3t 47 4 fi, TT Kubelet 会 
在 /vavlog/containers 下 生成 一 个 文件 软 连 接 Docker 存 储 的 容器 日 志 
件 ， 文 件 格 式 是 [podnamel [namespace] [container name]- 


[container_id].log: 


$ cat hello-world default hello- 
8c9df43b96227d14f8665d87d5b32ee39ce11328bd1d1848465- 


c3c9e97a09b8a. log 


{"log": "Hello World\n", "stream": "stdout", "time":"2015-12- 
04T11:28:29.016916036Z"} 


那么 Fluentd 将 读 取 这 个 日 志文 件 ， 对 应 的 tag 是 : 


kubernetes.var.log.containers.hello-world default hello- 
8c9df43b96227d14f8665d87d5b32ee39ce11328bd1d1848465c3c9e97a09b8 


a.log 


Fluentd 最 终 将 日 志 导 入 到 Elasticsearch， 通 过 检索 Elasticsearch 可 
以 查询 到 该 日 志 : 


{ 


_index": "logstash-2015.12.04", 
" type": "fluentd", 
" id": "AVFSOtILXx_4Q0Dgz43x", 
" Score": 6.7633038, 
" source": ( 
"log": "Hello World\n", 
"stream": "stdout", 
"docker": ( 

"container id": 
"8c9df43b96227d14f8665d87d5b32ee39ce11328bd1d1848465c3c9e97a09b 
8a" 
ty 
"kubernetes": { 

"namespace": "default", 


"pod name": "hello-world", 


"container name": "hello" 
ty 
"tag": 
"kubernetes.var.log.containers.hello-world_default_hello- 
8c9df43b96227d14f8665d87d5b32ee3 
9ce11328bd1d1848465c3c9e97a09b8a.1og", 


"Qtimestamp": "2015-12-04T11:28:29+00:00" 
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Kubernetes 系 统 在 长 时 间 运 行 后 ，Kubernetes Node 会 下 载 非常 多 的 
镜像 ， 其 中 可 能 会 存在 很 多 过 期 的 镜像 。 同 时 因为 运行 大 量 的 容器 ， 
容 需 退出 后 束 变 成 死亡 容 右 ， 将 数据 残留 在 宿主 机 上 ， 这 样 一 来 ， 过 
期 镜像 和 和 死亡 容器 都 会 占用 大 量 的 硬盘 空间 。 如 果 硬 一 空间 被 用 光 ， 
可 能 会 发 生 非 常 糟糕 的 情况 ， 甚 至 会 导致 硬盘 的 损坏 。 为 此 ，Kubelet 
会 进行 垃圾 清理 工作 ， 即 定期 清理 过 期 镜像 和 死亡 容器 。 


12.5.1 镜像 清理 


镜像 清理 的 集 上 略 古 当 硬盘 空间 使 用 率 超过 病 值 的 时 候 开 始 执 行 ， 
Kubelet 执 行 清理 的 时 候 优先 清理 最 久 没有 被 使 用 的 镜像 。 


fi Z3 T [RH] f AA EJ Be [E38 33. Kubelet A’) J 3) & BX --image-gc-high- 
threshold#/l--image-gc- low-thresholdf#7E ° 


12.5.2 ”容器 清理 


Kubelet 容 融 请 理 的 相关 参数 如 表 12-7 所 示 。 


312-7 Kubelet 容 器 清理 参数 


参数 Kubelet 启 动 参数 说 明 


SOL d BES TRA 


--minimum- : 
MinAge ES ar 除 的 最 小 TTL ， 默 
container-ttl-duration | 、 
认 是 1 分 钟 
--maximum-dead- 每 个 Pod 人 允许 存在 的 
MaxPerPodContainer containers-per- BAKIE ae el 
container H, SUAX2 
| ea 允许 存在 的 最 大 死 
--maximum-dead- rae ^ 
MaxContainers LA A, BRA 
containers 3 
ze 100 


Kubeletxe P] HUT Z& gs 3H ER, SEO IB DA EINER ILL Bae 
AER, iE UU. ZERO SERI [HI S ARE ECR e Kubelet^ Si 
除非 Kubelet 管 理 的 容器 » 


12.6 KubernetesÉJWeb 5 HI 


Kubemetes 提供 了 一 个 Web 界面 Kue UI 

(https://github.com/kubernetes/kube-ui) ， 用 来 图 形 化 展示 运行 环境 信 

息 。 安 装 方 法 可 参 孝 2.3.4 市 。 安 装 成 功 后 可 以 通过 Kubernetes API 
Server 的 接口 http://<kubernetes-master>/ui 进 行 访问 。 


Kube UI 站 页 图 形 化 展示 了 所 有 Kubernetes Node 的 资源 使 用 情况 ， 
包括 CPU、Memory 和 Filesystem 的 使 用 情况 ， 如 图 12-4 所 示 。 


图 12-4”Kube UI 首页 


单 击 首页 右上 和 角 的 View 按 钮 ， 包 售 Explore、Pods、Nodes、 
Replication Controllers 、Services 和 Events 等 选项 。 单 击 进入 Explore 页 
面 ， 会 列 出 所 有 Pod、Replication ControllerfllService, 3cfF Im VEALET I 
展示 ， 如 图 12-5 所 示 。 


图 12-5 Explore 页面 


同时 可 以 分 别 查 询 Pod、Replication Controller 和 Service 的 详细 信 
息 ， 比 如 查询 Service 的 详细 信息 ， 如 图 12-6 所 示 。 


图 12-6 查询 Service 的 详细 信息 


其 他 页 面 也 列 出 了 相应 的 信息 ， 比 如 查询 Event， 如 图 12-7 所 示 。 


-- Lash Sem Cre Bue Sai Sebjert Ree aree — 
Ael Mote Nodelioteydy uiid TAIE Node benod? statur is now: Rodeo Ready 
ee Node Modelo ay kubelet kubenader2 — Node kbe-node-? status is now: Nodeleady 
M, Mode Rodeo dy kdeletiibencdeJ Kode kdbe-node-3 status is novi Rodefeadr 
LA AL "ed TE ade NodelotBe ady Cle me Moda jbhernode-3 status is now: Wodellot Ready 
Mor 25, 2015 di Kiii anika i aa ai to ort DY costi sed requis aetrics daimed 
na ae UI nce cata eae n p d fale er 


图 12-7 查询 Event 


Kube UI 只 能 简单 地 查看 一 些 信 息 ， 不 能 进行 修改 ， 新 的 
Kubernetes Dashboard (https://github.com/kubernetes/dashboard) 正在 开 
发 中 ， 将 支持 功能 更 加 强大 的 Web 界 面 。 


第 3 部 分 
Kubernetes^E S 5i 


第 13 革  CoreOS 
Lr In 
14 Etcd 


%15% Mesos 


第 13 章 
CoreOS 
CoreOS 是 容器 生态 圈 重 要 的 一 环 ， 与 Kubernetes 和 Docker 都 有 着 非 


常 密切 的 关系 。 本 章 将 简单 介绍 CoreOS， 然 后 讲解 如 何 安装 CoreOS , 
以 及 如 何 使 用 CoreOS 运 行 Kubernetes。 


13.1 ”CoreOS 介 绍 


CoreOS 是 一 个 轻 量 级 、 容 器 化 的 Linux 发 行 版 ， 借 助 了 以 Docker 为 
代表 的 容 右 技术 ， 专 为 大 型 数据 中 心 而 设计 ， 由 在 通过 轻 量 的 系统 染 
构 和 灵活 的 应 用 程序 部 署 能 力 简 化 数据 中 心 的 维护 成 本 和 复杂 上 度 。 


CoreOS 没 有 提供 包 管 理工 具 ， 是 通过 容 希 化 的 运算 环境 癌 应 用 程 
序 提供 运算 资源 的 。 在 CoreOS 中 ， 所 有 应 用 程序 都 被 装 在 容 絮 中 运行 
在 操作 系统 之 上 ， 可 以 很 轻松 地 将 应 用 程序 在 操作 系统 之 间 转 移 。 


应 用 程序 之 间 共 享 系 统 内 核 和 货源 ， 但 是 彼此 之 间 又 互 不 可 见 。 
这 意味 着 应 用 程序 将 不 会 再 被 直 接 安 装 到 操作 系统 中 ， 而 是 运行 在 容 
器 中 。 这 种 方式 使 得 操作 系统 、 应 用 程序 及 运行 环境 之 间 的 耦合 度 大 
大 降低 。 相 对 于 传统 的 部 署 方 式 而 言 ， 在 CoreOS 集 群 中 部 署 应 用 程序 
更 加 灵活 便捷 ， 应 用 程序 运行 环境 之 间 的 干扰 更 少 ， 而 且 操 作 系 统 
身 的 维护 也 更 加 容易 。 


BBY A ARIRE], CoreOS n] AARE ATER SS, 3x 
小 化 定制 化 Linux 系 统 。 因 此 很 小 很 轻 量 ， 管 理 员 操 心 的 事情 会 少 很 
多 ， 人 允许 快速 修复 ， 占 据 的 空间 也 很 小 。 


在 一 定 程 度 上 减轻 了 维护 一 个 服务 器 集群 的 复杂 度 ， 可 帮助 用 户 
从 烦 珊 的 系统 及 软件 维护 工作 中 解脱 出 来 。 


132 ”CoreOS 工 具 链 


13.2.1 Etcd 


在 CoreOS 集 群 中 处 于 骨架 地 位 的 是 Etcd，Etcd 是 Core 团 队 开 发 的 一 
个 高 可 用 的 键 值 存储 系统 ， 灵 感 来 目 于 ZooKeeper 和 Doozer。Etcd 以 默 
认 的 形式 安装 于 每 个 CoreOS 系 统 之 中 ，CoreOS 集 群 中 的 程序 和 服务 可 
以 通过 Etcd 共 享 信息 或 服务 发 现 。 


13.2.2 Flannel 


Flannel Æ CoreOS H DÀ F BJ 48 zs Ij 28 LH, CoreOS % TE [s FH 
Flannel 创 建 的 一 个 容器 覆盖 网 络 ， 实 现 容器 之 间 的 通信 报 文 ， 实 现 跨 
主机 通信 。 


13.2.3 Rocket 


Rocket CoreOS#é HH A ak Aas 5| SE, MDockr h, ABATE A 
者 打包 应 用 和 依赖 包 到 可 移植 容器 中 ， 简 化 搭建 环境 等 部 署 工 作 。 
Rocket 同 Docker 相 比 更 加 专注 于 容 郁 核心 技术 和 容器 标 谁 。 


13.2.4 Systemd 


Systemd 是 Linux 下 的 一 种 mit 软 件 ， 由 Lennart Poettering 融 头 开发 ， 
并 在 LGPL 2.1 及 其 后 续 版 本 许可 证 下 开源 发 布 框架 以 表示 系统 服务 间 
的 依赖 天 系 ， 并 依 此 实现 系统 初始 化 时 服务 的 并 行 局 动 ， 同 时 达到 降 
低 Shell 的 系统 开销 的 效果 ， 最 终 代 巷 现在 常用 的 System V 与 BSD 风 格 
的 Init 程 序 ，CoreOS 已 将 Systemd 作 为 Linux 发 行 版 的 Init 系 统 。 


13.2.5 Fleet 


Fleet 是 一 个 通过 Systemd 对 CoreOS 集 群 进行 控制 和 管理 的 工具 。 
Fleet 与 Systemd 之 间 通 过 D-Bus API 进 行 交互 ， 每 个 FleetAgent 之 间 通 过 
Etcd 服 务 来 注册 和 同步 数据 。Fleet 提 供 的 功能 非常 丰富 ， 包 括 查 看 集群 
中 服务 器 的 状态 、 局 动 或 终止 Docker 容 器 、 读 取 日 志 内 容 等 。 更 为 重 
要 的 是 ，Fleet 可 以 确保 集群 中 的 服务 一 直 处 于 可 用 状态 。 当 出 现 某 个 
通过 Fleet 创 建 的 服务 在 集群 中 不 可 用 时 ， 如 由 于 某 台 主机 因为 硬件 或 
网 络 故障 从 集群 中 脱离 时 ， 原 本 运行 在 这 人 台 有 上 服务器 中 的 一 系列 服务 将 
通过 Fleet 被 重新 分 配 到 其 他 可 用 服务 硕 中 。 虽 然 当 前 Fleet 还 处 于 初期 
状态 ,但 是 其 管理 CoreOS 集 群 的 能 力 是 非常 有 效 的 ， 并 且 仍 然 有 很 大 
的 扩展 空间 ， 目 前 已 提供 简单 的 API 接 口供 用 户 集 成 。 


13.3 CoreOSXx EB 


13.3.1 ”安装 CoreOS 

本 节 将 使 用 Vagrant 部 署 CoreOS， 这 可 以 说 是 最 简单 的 方式 了 ， 可 
以 使 用 本 地 虚拟 机 快速 部 署 CoreOS 。 
准备 工作 

在 机 器 上 预先 装 好 VirtualBox 和 Vagrant: 

* VirtualBox 4.3.10 以 上 版 本 

。Vagrant 1.6 以 上 版 本 


下 载 CoreOS-Vagrant 仓 库 ， 其 中 包含 使 用 Vagrant 部 署 CoreOS 的 配 
置 文 件 : 


$ git clone https://github.com/coreos/coreos-vagrant 


$ cd coreos-vagrant 


配置 


f£ CoreOS-Vagrant & Æ H >K F, config.rb.sample fll user-data.sample 
XE PA SARL LF, TRIBUUNT BEBO TE n] BS] CoreOS af 4 ETT B XE X 
配置 ， 通 过 模板 文件 生成 配置 文件 : 


$ cp config.rb.sample config.rb 


$ cp user-data.sample user-data 


配置 文件 user-data 将 作为 CoreOS 操 作 系 统 初 始 化 时 使 用 的 Cloud- 
Init 配 置 文件 ，Cloud-mit 是 专 为 云 环境 中 虚拟 机 而 开发 的 工具 ， 它 根据 
配置 文件 对 虚拟 机 进行 系统 初始 化 配置 ， 配 置 文件 使 用 YAML 文 件 格 
式 ， 并 且 需 要 包含 #cloud-config: 


#cloud-config 
coreos: 
etcd2: 
#generate a new token for each unique cluster from 
https://discovery.etcd.io/new 
#discovery: https://discovery.etcd.io/«token» 
# multi-region and multi-cloud deployments need to use 
$public_ipv4 
advertise-client-urls: http://$public_ipv4:2379 
initial-advertise-peer-urls: http://$private_ipv4: 2380 
# listen on both the official ports and the legacy ports 
# legacy ports can be omitted if your application doesn't 
depend on them 
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 
listen-peer-urls: 
http://$private_ipv4:2380,http://$private_ipv4: 7001 
fleet: 
public-ip: $public_ipv4 
flannel: 
interface: $public_ipv4 
units: 


- name: etcd2.service 


command: start 
- name: fleet.service 
command: start 
- name: flanneld.service 
drop-ins: 
- name: 50-network-config.conf 
content: | 
[Service] 
ExecStartPre-/usr/bin/etcdctl set 
/coreos.com/network/config '( "Network": 
"10.1.0.0/16" }' 
command: start 
- name: docker-tcp.socket 
command: start 
enable: true 
content: | 
[Unit] 


Description-Docker Socket for the API 


[Socket ] 
ListenStream-2375 
Service=docker.service 
BindIPv60nly=both 
[Install] 


WantedBy=sockets. target 


Cloud-Init 配 置 文件 中 包含 了 Etcd、Fleet、Flannel 和 Docker 的 服务 
局 动 参数 ， 其 中 使 用 两 个 变量 $private_ipv4 和 $public_ipv4， 它 们 会 在 实 
际 运行 的 时 候补 目 动 蔡 换 为 虚拟 机 的 真实 外 网 IP 和 内 网 IP 地 址 。 用 户 可 
以 根据 需要 ， 在 配置 中 添加 更 多 定制 化 的 服务 和 配置 ， 具 体 信 息 可 用 


G https://coreos.com/docs/cluster-management/setup/cloudinit-cloud- 


config ° 


另外 ，CoreOS 集 群 是 用 Etcd 进 行 服 务 发 现 的 ，Cloud-Init 配 置 文件 
中 的 .coreos.etcd2. discovery 就 是 用 来 配置 一 个 外 部 Etcd 服 务 的 URL , 
CoreOS 启 动 时 通过 这 个 集群 标识 URL 地 址 自动 进入 同一 个 集群 中 ， 这 
瓯 实现 了 无 顷 人 工 干 预 的 集群 服务 硕 目 发 现 。 我 们 可 以 通过 Etcd 发 现 服 
& (discovery.etcd.io) 申请 创建 URL， 如 果 没 有 配置 的 话 ， 在 config.rb 
中 也 会 自动 申请 创建 进行 配置 。 


配置 文件 config.rb 中 包含 了 Vagrant 虚 拟 机 的 配置 ， 通 过 这 个 文件 可 
DÀ 78 x Vagrantfile 里 的 参数 。 我 们 主要 天 注 $num_instances 和 
$update_channel 这 两 个 参数 : 


。$num_instances 表 示 将 启动 的 CoreOS 集 群 中 需要 包含 主机 实例 的 


。$update_channel 表 示 启 动 的 CoreOS 实 例 使 用 的 升级 通道 ， 可 以 是 
stable、eta 或 alpha ° 


现在 配置 configrb， 将 部 署 有 1 个 节点 的 CoreOS 集 群 ， 并 使 用 alpha 
升级 通道 


$num_instances=1 


$update_channel='alpha' 


部 署 


使 用 Vagrant 部 署 CoreOS: 


$ vagrant up 


部 轩 成 功 后 ， 可 以 查询 虚拟 机 的 状态 : 


$ vagrant status 


Current machine states: 


core-01 running (virtualbox) 
core-02 running (virtualbox) 
core-03 running (virtualbox) 


This environment represents multiple VMs. The VMs are all listed 
above with their current state. For more information about a 
specific 


VM, run “vagrant status NAME . 


在 CoreOS 集群 运行 后 ， 集 群 的 实例 之 间 通 过 Etcd 实现 目 发 现 服 
同时 运行 起 Docker 和 Flannel， 形 成 连通 的 容 絮 集群 ， 可 以 SSH 到 
CoreOS P AFP: 


$ vagrant ssh core-01 


SK ja tECoreOS 5 点 中 查 询 服务 状态 : 


$ sudo systemctl status etcd2 docker flanneld 


13.3.2 ”使 用 CoreOS 运 行 Kubernetes 


Kubernetes 是 一 个 容 需 集群 管理 平台 ， 而 CoreOS 是 基于 容器 的 集群 
操作 系统 ， 两 者 可 以 说 有 着 生丝 TANER CoreOS 集 群 已 经 原生 运 
行 Docker， 同 时 使 用 Flannel 搭 建 出 容器 的 履 盖 网 络 ， 因 此 Kubernetes 非 
常 适合 运行 在 CoreOS 之 上 。 


现在 运行 3 个 世上 点 的 CoreOS 人 集群， 我 们 将 在 CoreOS 集 群 之 上 运行 
Kubernetes， 其 有 节点 将 作为 Kubernetes Node， 而 节点 core-01 同 时 
作为 Kubernetes Master ° 


启动 Kubelet 


CoreOS 在 alpha 开 发 版 (773.1.0 以 后 版 本 ) 中 集成 了 Kubernetes 的 
核心 组 件 Kubelet， 我 们 通过 在 所 有 节点 中 进行 简单 配置 束 可 以 启动 
kubelet， 从 而 作为 Kubernetes Node ° 


创建 kubelet Systemd 单 元 文件 /etc/systemd/system/kubelet.service: 


[Unit] 
Description=Kubernetes Kubelet 


Documentation=https://github.com/kubernetes/kubernetes 


[Service] 

ExecStartPre=/usr/bin/mkdir -p /etc/kubernetes/manifests 
ExecStart=/usr/bin/kubelet \ 
--api-servers-http://kuber-apiserver:8080 \ 


--allow-privileged=true \ 


--config=/etc/kubernetes/manifests \ 
--V=2 
Restart=on-failure 


RestartSec=5 


[Install] 


WantedBy=multi-user.target :qw 


ER, FRE TA core-01 上 运行 Kubernetes API Server， 所 以 -- 


api-servers 设置 的 URL 指 癌 core-01 ° 


配置 好 Systemd 单 元 文件 后 ， 使 用 systemctl 命 


$ sudo systemctl daemon-reload 


$ sudo systemctl start kubelet 


运行 后 用 systemctl 命 令 查询 Kubelet 是 否 运行 : 


$ sudo systemctl status kubelet 

另外 设置 kubelet 为 开机 自 启动 : 
$ sudo systemctl enable kubelet 
部 署 Kubernetes Master 


现在 在 节点 core-01 上 运行 Kubernetes Master, 
Master 失 jPod 定义 文件 : 


令 启 动 Kubelet: 


首先 下 载 Kubernetes 


$ wget 
https://raw. githubusercontent .com/coreos/pods/master/kubernetes. 


yaml 


然后 将 其 放 入 Kubelet 的 Manifest 有 目录 ， 由 Kubelet 以 Daemon Pod% 
形式 运行 Kubernetes Master 各 组 件 : 


$ sudo cp kubernetes.yaml /etc/kubernetes/manifests/ 


HARTA TEET, WAE ES, Kubernetes Master 的 各 个 组 
件 将 运行 起 来 。 


第 14 章 
Etcd 


Kubernetes 使 用 Etcd 进行 存储 ， 理 解 和 掌握 Etcd 对 于 管理 
Kubernetes 至 关 重 要 。 本 章 将 介绍 Etcd， 包 括 基本 概念 和 结构 组 织 ， 然 
后 详细 说 明 如 何 运 行 和 管理 Etcd。 


14.1 Etcd 介 绍 


Etcd 是 一 个 高 可 用 的 键 值 存储 系统 ，Etcd 的 灵感 来 自 于 ZooKeeper 
和 Doozer， 通 过 Raft 共 识 算 法 (The Raft Consensus Algorithm) 处 理 日 
志 复 制 以 保证 强 一 致 性 。 


Etcd 中 的 主要 概念 如 下 所 示 。 
° Raft: Etcd 所 采用 的 保证 分 布 式 系 统 强 一 致 性 的 算法 。 
e Node: 一 个 Raft 状 态 机 实例 。 


e Member: 一 个 Etcd 实 例 ， 它 管理 着 一 个 Node， 并 且 可 以 为 客户 
Vita TH fee HEARS ° * Cluster: 由 多 个 Member 构 成 可 以 协同 工作 的 Etcd 
集群 。 


。Peer: 对 同一 个 Etcd 集 群 中 另外 一 个 Member 的 称呼 。 


e Client: 癌 Etcd 集 群发 送 HTTP 请 求 的 客户 端 。 


WAL: 预 写 式 日 志 ，Etcd 用 于 持久 化 存储 的 日 志 格式 。 


。Snapshot: Etcd 防 止 WAL 文 件 过 多 而 设置 的 快照 ， 存 储 Etcd 数 据 
状态 。 


。Proxy: Etcd 的 一 种 模式 ， 为 Etcd 集 群 提供 反问 代理 服务 。 


e Leader: Raft 泪 法 中 通过 竞选 而 产生 的 处 理 所 有 数据 提交 的 市 


e Follower: 竞选 失败 的 节点 作为 Raft 中 的 从 属 丰 点 ， 为 算法 提供 
强 一 致 性 傈 证 。 


e Candidate: 当 Follower 超 过 一 定时 间接 收 不 到 Leader 的 心跳 时 转 
57H Candidate7T IIR 75396 » 


e Tem: EATARRA Leader $] P — 1X 5a 20 HY AY IBI, BRS 


Term ? 


e Index: 数据 项 编号 。Raft 中 通过 Term 和 Index 来 定位 数据 。 


14.2 ”Etcd 的 结构 


Etcd 主 要 分 为 4 个 部 分 ， 如 图 14-1 所 示 。 


HTTP Server 


Entry 


Snapshot 


图 14-1 Etcd 的 结构 


。HTTP Server: 用 于 处 理 用 户 发 送 的 API 请 求 以 及 其 他 Etcd 世 点 的 
同步 与 心跳 信息 请 求 。 


e Store: 用 于 处 理 Etcd 文 持 的 各 类 功能 的 事务 ， 包 括 数 据 索 引 、 
节点 状态 变更 、 监 控 与 有 反馈、 事件 处 理 与 执行 等 ， 是 Etcd 对 用 户 提 供 
的 大 多 数 API 功 能 的 具体 实现 。 


“ Raft: 强 一 致 性 算法 的 具体 实现 ， 是 Etcd 的 核心 。 


e WAL: Write Ahead Log (SAHE) ， 是 Etcd 的 数据 存储 方 
式 ， 是 用 于 癌 系 统 提供 原子 性 和 持久 性 的 一 系列 技术 。 在 使 用 WAL 的 
时 候 ， 所 有 的 修改 在 提交 之 前 都 要 先 写 入 日 志文 件 中 。Etcd 的 WAL 由 
日 志 存 储 与 快照 存储 两 部 分 组 成 ， 其 中 ，Entry 负 责 存储 具体 日 志 的 内 


容 ， 而 Snapshot 负 责 在 日 志 内 容 发 生变 化 的 时 候 保存 Raft 的 状态 。 
WAL 会 在 本 地 磁盘 的 一 个 指定 目录 下 分 别 存放 日 志和 条目 与 快照 内 容 。 


通常 ， 一 个 用 户 的 请 求 发 送 过 来 ， 会 经 由 HTTP Server 转 发 给 Store 
进行 具体 的 事务 处 理 。 如 采 涉 及 节点 的 修改 ， 则 交 给 Raft 模 块 进行 状 
态 的 变更 、 日 志 的 记录 ， 然 后 再 同步 给 其 他 Etcd 节 点 以 确认 数据 提 
交 ， 最 后 进行 数据 的 提交 、 再 次 同步 。 


Etcd 属 于 分 布 式 架 构 ， 其 中 的 通信 模型 有 两 种 ， 一 种 是 Etcd Client 
同 Etcd Server 之 间 的 通信 ， 男 一 种 是 Etcd Peer 之 间 的 通信 o 


14.2.1 Client-to-Server 


在 默认 设置 下 ，Etcd 通 过 主机 的 2379/4001 端 口 向 Client 提 供 服 
务 ， 每 个 主机 上 的 应 用 程序 都 可 以 通过 主机 的 2379/4001 端 口 以 HTTP 
+ JSON 的 方式 向 Etcd 读 写 数据 。 写 入 的 数据 会 由 Etcd 同 步 到 集群 的 其 
他 节点 中 ， 如 图 14-2 所 示 。 


图 14-2 Etcd Client 同 Etcd Server 之 间 的 通信 


14.2.2 Peer-to-Peer 


在 默认 设置 下 ，Etcd 通 过 主机 的 2380/7001 端 口 在 各 个 节点 中 同步 
Raft 状 态 及 数据 ， 如 图 14-3 所 示 。 


图 14-3 Etcd Peer 之 间 的 通信 


14.3 ”Etcd 实 践 


14.3.1 ”运行 Etcd 


可 以 从 Github 上 下 载 指定 版 本 的 Etcd 发 布 包 进 行 安装 : 


$ wget 
https://github.com/coreos/etcd/releases/download/v2.2.0/etcd- 
v2.2.0-linux-amd64. tar.gz $ tar xzvf etcd-v2.2.0-linux- 


amd64.tar.gz 


$ cd etcd-v2.2.0-linux-amd64 


$ cp ./etcd /usr/bin 


局 动 单 万 点 的 Etcd: 


$ etcd -name etcd \ 

-data-dir /var/lib/etcd \ 

-listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 \ 
-advertise-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 


fEEtcdW ABER +, -namei EEtcd AWG FR, -data-dirix & 
EtcdH arte A ae ° HY}, -listen-client-urlsix & f Etcd[u] Client EARS 
的 监听 URL， 多 个 URL 直 接 用 过 号 分 隔 ， 而 -advertise-client-urls 指 定 了 
Etcd 对 外 广播 的 URL， 需 要 在 -listen-clientrurls 配 置 URL 范 围 。 


14.3.2 ”Etcd 集 群 化 


Etcd 和 集群 的 工作 原理 基于 Raft 共 识 算 法 。Raft 共 识 算法 的 优点 在 
于 ， 可 以 在 高 效 地 解决 分 布 式 系统 中 各 个 节点 日 志 内 容 一 致 性 问题 的 
同时 ， 也 使 得 集群 具备 一 定 的 容错 能 力 ， 即 使 集群 中 出 现 部 分 节点 故 
障 、 网 络 故 障 等 问题 ， 仍 可 保证 其 余 大 多 数 方 点 正确 地 步 进 ， 甚 至 当 
BAIR 〈 一 般 来 说 超过 集群 节点 总 数 的 一 半 ) 出 现 故 障 而 导致 集 
群 不 可 用 时 ， 依 然 可 以 保证 节点 中 的 数据 不 会 出 现 错 误 的 结 采 。 


因为 需要 选举 Leader 闻 点 ， 所 以 Etcd 集 群 至 少 需 要 两 个 节点 ， 但 
是 如 果 是 两 个 成 员 ， 那 么 在 一 台 无 法 正常 运转 的 情况 下 ， 剩 下 的 一 个 


也 无 法 正常 工作 ， 一 般 建议 是 3~9 个 和 节点， 并且 一 个 重要 的 集群 优化 
策略 是 要 保障 集群 中 活跃 万 点 的 数目 始终 为 奇数 个 。 


14.3.2.1 搭建 集群 


要 搭建 Etcd 集 群 ， 需 要 让 EtcdT 点 互相 发 现 ， 目 前 提供 的 发 现 方 
式 有 3 种 : 


“静态 发 现 

。Etcd 动 态 发 现 

。DNS 服 务 发 现 

现在 我 们 通过 搭建 3 个 节点 的 Etcd 集 群 ， 如 表 14-1 所 示 ， 分 别 介绍 


3 种 方式 的 配置 方法 。 


表 14-1 ”Etcd 集 群 环境 


节点 主机 名 IP 
Etcd1 etcd1.example.com 192.168.3.140 


Etcd3 etcd3.example.com 192.168.3.142 


静态 服务 发 现 是 最 简单 的 一 种 搭建 方式 ， 这 要 求 事先 知道 Etcd 集 
群 的 数目 以 及 每 个 市 点 的 地 址 ， 然 后 在 每 个 Etcd 广 点 静态 地 配置 初始 


的 Etcd 集 群 信息 : 


-initial-cluster 
etcdi=http://192.168.3.140: 2380, etcd2=http://192.168.3.141:2380 
,etcd3= http://192.168.3.142:2380 


-initial-cluster-state new 


其 中 ，-initial-cluster-state=new 表 示 这 是 在 从 无 到 有 搭建 Etcd 集 
群 。 人 参数 -initial-cluster 摘 述 了 这 个 新 集群 中 共有 哪些 节点 ， 其 中 每 个 


斑点 用 name=ur 的 形式 描述 ， 节 点 之 间 用 过 号 分 隔 ， 并 且 指 定 的 URL 
是 Etcd 的 广播 Peer 地 址 ， 即 需 SERT initial advertise-peer-urls 参 数 设 置 得 
Says 


分 别 在 3 个 节点 上 启动 Etcd: 
。 Etcd1 


$ etcd -name etcd1 ^ 

-data-dir /var/lib/etcd1 \ 

-listen-peer-urls http://192.168.3.140:2380 \ 
-initial-advertise-peer-urls http://192.168.3.140:2380 \ 
-listen-client-urls 
http://192.168.3.140:2379,http://127.0.0.1:2379 \ 
-advertise-client-urls http://192.168.3.140:2379 \ 
-initial-cluster 
etcdi=http://192.168.3.140: 2380, etcd2-http://192.168.3.141:2380 
,etcd3=http://192.168.3.14 


2:2380 \ 


-initial-cluster-state new 


* Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-peer-urls http://192.168.3.141:2380 \ 
-initial-advertise-peer-urls http://192.168.3.141:2380 \ 
-listen-client-urls 
http://192.168.3.141:2379,http://127.0.0.1:2379 \ 
-advertise-client-urls http://192.168.3.141:2379 \ 
-initial-cluster 
etcdi=http://192.168.3.140: 2380, etcd2-http://192.168.3.141:2380 
,etcd3= http://192.168.3.142:2380 \ 


-initial-cluster-state new 


* Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.142:2380 \ 
-initial-advertise-peer-urls http://192.168.3.142:2380 \ 
-listen-client-urls 
http://192.168.3.142:2379,http://127.0.0.1:2379 \ 
-advertise-client-urls http://192.168.3.142:2379 \ 
-initial-cluster 


etcdi=http://192.168.3.140:2380, etcd2-http://192.168.3.141:2380 


,etcd3= http://192.168.3.142:2380 \ 


-initial-cluster-state new 


动态 发 现 适 用 于 无 法 事先 知道 Etcd 集 群 规模 和 每 个 节点 地 址 的 场 
景 ， 包 括 Etcd 动 态 发 现 和 DNS 动态 发 现 。 


Etcd 动 态 发 现 


Etcd 动 态 发 现 方式 是 利用 一 个 已 有 的 Etcd 服 务 来 提供 服务 发 现 ， 
从 而 搭建 出 一 个 新 的 Etcd 集 群 。 


CoreOS 官 方 提供 了 免费 的 Etcd 发 现 服务 (discovery.etcd.io) ， 可 
以 用 来 帮助 初始 化 狐 Etcd 集 群 。 通 过 浏 贤 器 或 者 命令 行 curl 访 问 地 址 
https://discovery.etcd.io， 可 以 得 到 一 个 新 的 集群 标识 URL， 比 如 创建 
规模 数目 为 3 的 集群 标识 URL: 


$ curl -w "An" 'https://discovery.etcd.io/new?size-3' 


https://discovery.etcd.i0o/e1839e0d76aa687cb7c9bafcdfA420f66 


输出 的 URL 是 搭建 Etcd 和 集群 需要 使 用 到 的 ， 可 通过 环境 变量 设 
置 : 


$ export ETCD CLUSTER DISCOVERY URL-https://discovery.etcd.io/ 
e1839e0d76aa687cb7c9bafcdf420f66 


如 果 无 法 使 用 discovery.etcd.io， 也 可 以 利用 已 有 的 Etcd ARB, Et 
如 Etcd 服 务 访问 地 址 是 http://myetcd.local， 我 们 同样 需要 创建 新 的 集 
群 标识 URL， 首 先生 成 一 个 UUID: 


$ export ECTD_CLUSTER_UUID=$(cat /dev/urandom | base64 | tr -d 
"=+/" | dd bs=40 count=1 2» /dev/null) 

$ echo $ECTD_CLUSTER_UUID 
Batno20LUGhFICsmuZiQgM7tG1Z84h2jLnmkLyf2 


然后 创建 集群 标识 Key， 其 中 设置 集群 规模 数目 为 3: 


$ curl -X PUT 
http://myetcd.1local/v2/keys/discovery/${ECTD_CLUSTER_UUID}/_con 
fig/size -d value=3 

{"action":"set", "node": 
{"key":"/discovery/Batno20LUGhFICsmuZiQgM7tG1Z84h2jLnmkLyf2/_co 
nfig/size","value":"3","modifiedIndex":3998, "createdIndex" : 3998 
}} 


通过 环境 变量 设置 集群 标识 URL: 


$ export 
ETCD_CLUSTER_DISCOVERY_URL=http://myetcd.local/v2/keys/discover 
y/${ECTD_ CLUSTER_UUID} 


在 搭建 新 集群 的 时 候 ， 需 要 通过 -discovery 参 数 指定 我 们 创建 的 
URL， 分 别 在 3 个 节点 上 启动 Etcd: 


* Etcd1 


$ etcd -name etcd1 \ 
-data-dir /var/lib/etcd1 \ 


-listen-peer-urls http://192.168.3.140:2380 \ 


-initial-advertise-peer-urls http://192.168.3.140:2380 \ 
-listen-client-urls 

http: //192.168.3.140:2379,http://127.0.0.1:2379 \ -advertise- 
client-urls http://192.168.3.140:2379 \ 

-discovery ${ETCD_CLUSTER_DISCOVERY_URL} \ 


-initial-cluster-state new 


* Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-peer-urls http://192.168.3.141:2380 \ 
-initial-advertise-peer-urls http://192.168.3.141:2380 \ 
-listen-client-urls 
http://192.168.3.141:2379,http://127.0.0.1:2379 \ 
-advertise-client-urls http://192.168.3.141:2379 \ 
-discovery $[ETCD CLUSTER DISCOVERY URL) \ 


-initial-cluster-state new 


* Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.142:2380 \ 
-initial-advertise-peer-urls http://192.168.3.142:2380 \ 
-listen-client-urls 
http://192.168.3.142:2379,http://127.0.0.1:2379 \ 


-advertise-client-urls http://192.168.3.142:2379 \ 


-discovery ${ETCD_CLUSTER_DISCOVERY_URL} \ 


-initial-cluster-state new 


DNS 动态 发 现 


在 DNS 中 ， 一 个 域名 能 够 关联 若干 种 资源 记录 ， 除 了 我 们 比较 就 
悉 的 A 记录 (用 于 地 址 查询 ) 或 者 是 MX 记录 (用 于 邮件 服务 查询 ) 
DNS 还 定义 了 SRV 记 录 ， 可 以 用 于 服务 发 现 。 


Etcd 支 持 利 用 DNS SRV 记 了 录 实 现 互相 发 现 ， ee 
数 设 置 DNS SRV 域 名 ， 比 如 设置 成 example.com， 然 后 Etcd 会 依次 进 
查询 。 


_etcd-server-ssl._tcp.example.com 


_etcd-server. tcp.example.com 


Qi 5 etcd-server-ssl. tcp.example.com At 9r EZ], HA Etdi zs f 
用 HTTPS/SSL 启 动 。 


对 于 我 们 要 搭建 的 集群 ， 首 先 要 创建 DNS SRV 记录 : 


$ dig +noall +answer SRV _etcd-server._tcp.example.com 
.etcd-server. tcp.example.com. 300 IN SRV © © 2380 
etcd1.example.com. 

.etcd-server. tcp.example.com. 300 IN SRV © © 2380 
etcd2.example.com. 

_etcd-server. tcp.example.com. 300 IN SRV © © 2380 


etcd3.example.com. 


$ dig +noall +answer  etcdi.example.com  etcd2.example.com 
etcd3.example.com 

etcdi.example.com. 300 IN A 192.168.3.140 

etcd2.example.com. 300 IN A 192.168.3.141 


etcd3.example.com. 300 IN A 192.168.3.142 
然后 分 别 在 3 个 廊 点 上 局 动 Etcd 。 
e Etcd1 


$ etcd -name etcd1 \ 

-data-dir /var/lib/etcd1 \ 

-listen-client-urls http://etcd1.example.com:2379 \ 
-advertise-client-urls http://etcd1.example.com:2379 \ 
-listen-peer-urls http://etcd1.example.com:2380 \ 
-initial-advertise-peer-urls http://etcd1.example.com:2380 \ 
-discovery-srv example.com \ 


-initial-cluster-state new 


* Etcd2 


$ etcd -name etcd2 \ 

-data-dir /var/lib/etcd2 \ 

-listen-client-urls http://etcd2.example.com:2379 \ 
-advertise-client-urls http://etcd2.example.com:2379 \ 
-listen-peer-urls http://etcd2.example.com:2380 \ 


-initial-advertise-peer-urls http://etcd2.example.com:2380 \ 


-discovery-srv example.com \ 


-initial-cluster-state new 


* Etcd3 


$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-client-urls http://etcd3.example.com:2379 \ 
-advertise-client-urls http://etcd3.example.com:2379 \ 
-listen-peer-urls http://etcd3.example.com:2380 \ 
-initial-advertise-peer-urls http://etcd3.example.com:2380 \ 
-discovery-srv example.com \ 


-initial-cluster-state new 


14.3.2.2 ”集群 管理 


Etcd 集 群 搭建 完成 后 ， 可 以 查询 集群 成 员 : 


$ etcdctl member list 

f042ea167d8f2828: name=etcd1 peerURLs-http://192.168.3.140:2380 
clientURLs-http://192.168.3.140:2379 

156ce626171618a6: name=etcd2 peerURLs-http://192.168.3.141:2380 
clientURLs-http://192.168.3.141:2379 

c99b1511c3ade2bb: name=etcd3 peerURLs-http://192.168.3.142:2380 


clientURLs-http://192.168.3.142:2379 


以 及 集群 的 健康 状态 : 


$ etcdctl cluster-health 
member f042ea167d8f2828 is healthy: got healthy result 
http://192.168.3.140:2379 
member 156ce626171618a6 is healthy: got healthy result 
http://192.168.3.141:2379 
member c99b1511c3ade2bb is healthy: got healthy result 
http://192.168.3.142:2379 


cluster is healthy 


增加 成 员 
YAS DN BMG EA fe e: 


$ etcdctl member add etcd4 http://192.168.3.143:2380 


added member A4d906f7a642c3f23 to cluster 


ETCD_NAME="etcd4" 

ETCD INITIAL CLUSTER-"etcdi-http://192.168.3.140:2380 
etcd2-http://192.168.3.141:2380 
etcd3-http://192.168.3.142:2380 
etcd4-http://192.168.3.143:2380" 


ETCD INITIAL CLUSTER STATE-existing 


from 


from 


from 


添加 成 功 后 返回 的 信息 中 提示 设置 环境 变量 etcd_name、 
etcd initial _ cluster 和 etcd_initial cluster state ， 这 将 可 以 在 启动 新 的 


Etcd 成 员 时 使 用 : 


$ etcd -name etcd4 \ 

-data-dir /var/lib/etcd4 \ 

-listen-client-urls http://192.168.3.143:2379 \ 
-advertise-client-urls http://192.168.3.143:2379 \ 
-listen-peer-urls http://192.168.3.143:2380 \ 
-initial-advertise-peer-urls http://192.168.3.143:2380 \ 
-initial-cluster $ETCD_INITIAL_CLUSTER \ 


-initial-cluster-state existing 


最 后 ， 可 以 查询 到 新 的 成 员 列 表 : 


$ etcdctl member list 

f042ea167d8f2828: name=etcd1 peerURLs-http://192.168.3.140:2380 
clientURLs-http://192.168.3.140:2379 

156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 
clientURLs-http://192.168.3.141:2379 

c99b1511c3ade2bb: name=etcd3 peerURLs-http://192.168.3.142:2380 
clientURLs-http://192.168.3. 142:2379 

4d906f7a642c3f23: name=etcd4 peerURLs-http://192.168.3.143:2380 
clientURLs-http://192.168.3.143:2379 


删除 成 员 


$ etcdctl member remove 4d906f7a642c3f23 


Removed member 4d906f7a642c3f23 from cluster 


$ etcdctl member list 
f042ea167d8f2828: name=etcd1 peerURLs-http://192.168.3.140:2380 


clientURLs-http://192.168.3.140:2379 
156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 
clientURLs-http://192.168.3.141:2379 
c99b1511c3ade2bb: name=etcd3 peerURLs-http://192.168.3.142:2380 
clientURLs-http://192.168.3.142:2379 


更 新 成 员 


$ etcdctl member update f042ea167d8f2828 
http: //etcd1.example.com:2380 


Updated member with ID f042ea167d8f2828 in cluster 


$ etcdctl member list 

f042ea167d8f2828: name-etcdi 
peerURLs=http://etcd1.example.com: 2380 
clientURLs-http://192.168.3.140:2379 

156ce626171618a6: name=etcd2 peerURLS=http://192.168.3.141:2380 
clientURLs-http://192.168.3.141:2379 

c99b1511c3ade2bb: name=etcd3 peerURLs-http://192.168.3.142:2380 
clientURLs-http://192.168.3.142:2379 


迁移 成 员 


当 需 要 迁移 成 员 的 时 候 ， 实 际 上 等 效 于 删除 一 个 旧 成 员 ， 再 新 增 
一 个 新 成 员 ， 让 数据 自动 切换 ， 但 是 如 果 数 据 过 大 (大 于 50MB) , 
会 影响 集群 的 状态 。 更 安全 的 做 法 是 人 为 地 迁移 数据 ， 比 如 现在 需 
将 Etcd EX 5i etcd3 M HL # 1 ( 192.168.3.142 ) 迁移 机 器 2 
(192.168.3.143) ， 步 又 如 下 ° 


e 首先 在 机 万 1 上 停止 Etcd 进 程 ， 打 包 数 据 并 复制 到 机 器 2: 


$ kill ‘pgrep etcd. 
$ tar -cvzf etcd3.data.tar.gz /var/lib/etcd3 


$ scp etcd3.data.tar.gz 192.168.3.143:~/ 
紧 接 着 更 新 Etcd 成 员 : 


$ etcdctl member update c99b1511c3ade2bb 
http: //192.168.3.143:2380 


Updated member with ID c99b1511c3ade2bb in cluster 


然后 在 机 器 2 上 启动 Etcd: 


$ tar -xzvf etcd3.data.tar.gz -C /var/lib/etcd3 

$ etcd -name etcd3 \ 

-data-dir /var/lib/etcd3 \ 

-listen-peer-urls http://192.168.3.143:2380 \ 
-initial-advertise-peer-urls http://192.168.3.143:2380 \ 
-listen-client-urls 

http: //192.168.3.143:2379,http://127.0.0.1:2379 \ 


-advertise-client-urls http://192.168.3.143:2379 


14.3.3 Etcd Proxy Bt, 


Etcd 可 以 设置 为 Proxy 模 式 ， 此 时 Etcd Proxy 并 不 是 直接 加 入 到 数 
据 强 一 致 性 的 Etcd 集 群 中 ， 所 以 Etcd Proxy 并 没有 增加 集群 的 可 靠 性 ， 


当然 也 没有 降低 集群 的 写 入 性 能 。Etcd Proxy 只 是 作为 一 个 反 辐 代理 把 
客户 的 请 求 转发 给 可 用 的 Etcd 集 群 。 一 个 典型 的 应 用 场景 是 ， 在 客户 
端 机 器 本 地 运行 Etcd Proxy 来 对 接 真正 的 Etcd 服 务 端 集 群 ， 对 客户 端 应 
用 来 说 可 以 直接 访问 本 地 的 Etcd Proxy (http://127.0.0.1:2379) ， 而 不 
用 感知 Etcd 服 务 端 集群 的 变化 ， 因 为 Etcd Proxy 会 维护 同 Etcd 服 务 端 集 
群 的 同步 。 


启动 一 个 Etcd Proxy， 对 接 Etcd 集 群 : 
* 静态 发 现 


$ etcd -proxy on \ 

-listen-client-urls http://127.0.0.1:4001 \ 

-initial-cluster 

etcdi=http://192.168.3.140: 2380, etcd2=http://192.168.3.141:2380 
, etcd3=http://192.168.3.142:2380 


* Etcd 动 态 发 现 


$ etcd -proxy on \ 
-listen-client-urls http://127.0.0.1:4001 \ 


-discovery ${DISCOVERY_URL} 
"DNS 动态 发 现 


$ etcd --proxy on \ 
-listen-client-urls http://127.0.0.1:4001 \ 


-discovery-srv example.com 


14.3.4 ”Etcd 的 安全 模式 


Etcd 中 的 通信 包括 Client-to-Server 和 Peer-to-Peer， 文 持 SSL/TLS 加 
密 和 Client Certificate Authentication 认 证 。 


Client-to-Server 通 信 
。 开 启 HTTPS 


开启 HTTPS， 需 要 CA 证 书 (server-ca.crt) 和 该 CA 签发 的 服务 端 
密 钥 对 (server.crt/ server.key) 。 运 行 Etcd: 


$ etcd -name etcdi \ 
-cert-file=/path/to/server.crt -key-file=/path/to/server.key \ 
-advertise-client-urls=https://127.0.0.1:2379 \ 


-listen-client-urls=https://127.0.0.1:2379 


Etcd Client i# it HTTPS i Ù] Etcd Server 时 就 需要 提供 CA 证 书 


(server-ca.crt) 


$ etcdctl --ca-file=/path/to/server-ca.crt -C 
https://127.0.0.1:2379 cluster-health 

member ce2a822cea30bfca is healthy: got healthy result from 
https://127.0.0.1:2379 


cluster is healthy 


¢ Ff Ja Client Certificate Authentication 


在 开启 HTTPS 后 ， 可 以 开启 Client Certificate Authentication ° 3x 4E 
一 来 ，Etcd Client 在 访问 Etcd Server 的 时 候 就 需要 提供 Client Certificate 
进行 认证 ， 认 证 成 功 才 能 有 权限 访问 。 


同样 的 ， 需 要 CA 证 书 (client-ca.crt) 和 该 CA 签发 的 客户 端 密 钥 对 
(client.crUclient.key) ， 签 发 客户 端 密 钥 对 和 签发 服务 端的 CA 可 以 一 
样 ， 这 实际 上 并 不 神 突 ， 因 为 一 个 CA 可 以 同时 签发 服务 端 密 钥 对 和 客 
户 端 密 钥 对 。 运 行 Etcd: 


$ etcd -name etcd1 -data-dir etcd1 \ 

-client-cert-auth -trusted-ca-file=/path/to/client-ca.crt \ 
-cert-file=/path/to/server.crt -key-file=/path/to/server.key \ 
-advertise-client-urls https://127.0.0.1:2379 \ 


-listen-client-urls https://127.0.0.1:2379 


如 Etcd Client 按 照 之 前 的 命令 访问 Etcd Server， 会 报错 : 


$ etcdctl --ca-file=/path/to/server-ca.crt -C 
https://127.0.0.1:2379 cluster-health 

cluster may be unhealthy: failed to list members 

Error: client: etcd cluster is unavailable or misconfigured 


error Z0: remote error: bad certificate 


因为 Etcd Client 2242 Client Certificate， 才 能 认证 成 功 : 


$ etcdctl --ca-file=/path/to/server-ca.crt \ 
--key-file=/path/to/client.key --cert-file=/path/to/client.crt 
\ 

-C https://127.0.0.1:2379 \ 


cluster-health 
member ce2a822cea30bfca is healthy: got healthy result from 
https://127.0.0.1:2379 


cluster is healthy 


Peer-to-Peer 通 信 
。 开 局 HITPS 和 Client Certificate Authentication 


类 似 的 ，Etcd Peer 之 间 的 通信 开局 HITPS 和 Client Certificate 
Authentication ， 需 要 准备 CA 证 书 (cacrt) ， 为 每 个 Peer 签 发 一 个 密 钥 


对 (serverl.key#llserverl.crt, server2.key 和 server2.crt) ° 


* Etcd1 


$ etcd -name etcdi \ 

-peer-client-cert-auth -peer-trusted-ca-file=/path/to/ca.crt \ 
-peer-cert-file-/path/to/serveri.crt -peer -key- 
file=/path/to/serveri.key \ 
-listen-peer-urls-https://192.168.3.140:2380 \ 
-initial-advertise-peer-urls=https://192.168.3.140:2380 \ 
-initial-cluster 
etcdi=https://192.168.3.140: 2380, etcd2=https://192.168.3.141:23 
80 \ 


-initial-cluster-state new 


* Etcd2 


$ etcd -name etcd2 \ 

-peer-client-cert-auth -peer-trusted-ca-file=/path/to/ca.crt \ 
-peer-cert-file=/path/to/server2.crt -peer -key- 
file-/path/to/server2.key \ 
-listen-peer-urls-https://192.168.3.141:2380 \ 
-initial-advertise-peer-urls-https://192.168.3.141:2380 \ 
-initial-cluster 
etcdi=http://192.168.3.140: 2380, etcd2=http://192.168.3.141:2380 
, etcd3=http://192.168.3.142:2380 \ 

-initial-cluster 
etcdi=https://192.168.3.140: 2380, etcd2=https://192.168.3.141:23 
80 \ 


-initial-cluster-state new 


第 15 章 


Mesos 


Mesos 是 一 个 成 熟 的 架构 ， 一 方面 提供 了 同 Kubernetes 类 似 的 容器 
集群 管理 方案 ; 另 一 方面 ，Mesos 正 积极 同 Kubernetes 进 行 整 合 ， 
Mesos $ Kubernetes J aX Zh AC » AS EEE IP 2A Mesos, LK Marathon fl 
K8SM， 最 后 说 明 如 何 使 用 这 3 个 项 目 。 


15.1 Mesos 介 绍 


Apache Mesos 是 由 加 州 大 学 伯克利 分 校 的 AMPLab 首 先 开发 的 一 
球 开 源 集 群 管理 软件 ， 支 持 Hadoop 、Elasticsearch、Spark、Storm 和 和 
Kafka 等 架构 。 其 开源 性 越 来 越 受到 一 些 大 型 云 计 算 公 司 的 青睐 ， 
Twitter 和 Airbnb 公 司 已 经 将 其 大 规模 应 用 在 其 数据 中 心中 了 。 现 在 ， 
一 家 初创 公司 Mesosphere 将 Mesos 定 位 为 数据 中 心 操 作 系 统 (Data 
Center Operating System, DCOS) ， 使 之 步 入 主流 。 


Mesos 在 多 种 不 同类 型 的 工作 之 间 共 享 机 器 〈 或 者 节点 ) 的 可 用 
资源 ， 如 图 15-1 所 示 。Mesos 可 以 看 作 是 数据 中 心 的 内 核 ， 提 供 所 有 市 
所 人 闹 源 的 统一 视图 ， 所 起 的 作用 类 似 于 操作 系统 内 核 在 单 台 机 絮 上 的 
作用 ， 可 以 无 缝 地 访问 多 节点 资源 。 


| ^. | NN 


图 15-1 MesosH EK 


15.2 ”Mesos 的 架构 


Mesos 的 架构 如 图 15-2 所 示 ， 主 要 的 角色 有 Mesos Master ^ Mesos 


Slave、Framework 和 Executor ° 


ZooKeeper 
quorum 


Hadoop MPI 
Executor Executor 


图 15-2 Mesos 架 构 


e Mesos Master 是 整个 系统 的 核心 ， 负 次 管 理 接 入 Mesos 的 各 个 
Framework 和 Mesos Slave， 并 将 Mesos Slave 上 的 资源 按照 其 种 策略 分 


配给 Framework ° 


* Mesos Slave 人 负责 接收 并 执行 来 自 Mesos Master 的 命令 、 管 理 世 点 
上 的 任务 ， 并 为 各 个 任务 分 配 资 源 。Mesos Slave 将 目 己 的 资源 量 发 送 
给 Mesos Master， 由 Mesos Master 决 定 将 资源 分 配给 哪个 Framework,， 
并 且 当 任务 运行 时 ，Mesos Slave 会 将 任务 放 到 包含 固定 资源 的 Linux 容 
怖 中 运行 ， 以 达到 资源 隔离 的 效果 。 


。Framework 是 指 外 部 的 计算 框架 ， 如 Hadoop、Elasticsearch ^ 
Spark ^ Storm 和 Kafka 等 ， 这 些 计 算 框 架 可 通过 注册 的 方式 接 入 
Mesos， 以 便 Mesos 进 行 统一 管理 和 资源 分 配 。Mesos 要 求 可 接 入 的 
Framework 必 须 有 一 个 调度 器 模块 ， 该 调度 器 人 负责 Framework 内 部 的 任 
务 调 度 。 当 一 个 Framework 想 要 接 入 Mesos 时 ， 需 要 修改 自己 的 调度 


右 ， 以 便 回 Mesos 注 册 ， 并 获取 Mesos 分 配给 目 己 的 资源 ， 这 样 再 由 调 
度 器 将 这 些 资 源 分 配给 Framework 中 的 任务 。 也 就 是 说 ， 整 个 Mesos 系 
统 采用 了 双 层 调度 框架 : 第 一 层 ， 由 Mesos 将 资源 分 配给 Framework; 
第 二 层 ，Framework 的 调度 需 将 资源 分 配给 目 己 内 部 的 任务 。 


* Executor 主要 用 于 局 动 Framework 内 部 的 任务 。 由 于 不 同 的 
Framework 局 动 任务 的 接口 或 者 方式 不 同 ， 当 一 个 新 的 Framework 要 接 
入 Mesos 时 ， 需 要 编写 一 个 Executor， 告 诉 Mesos 如 何 局 动 该 Framework 
中 的 任务 。 


15.3 “Marathon 和 K8SM 介 绍 


15.3.1 Marathon 


Marathonzé — T Mesos Framework， 正 如 其 名 字 “ 马 拉 松 ”， 用 来 文 
导 运 行 长 期 服务 ， 比 如 Web 应 用 等 。Marathon 能 够 保证 这 些 服务 的 高 
可 用 性 ， 也 就 是 说 ， 当 某 台 机 妖 发 生 故 障 时 ， 能 够 在 其 他 机 器 上 启动 
服务 。Marathon 是 集群 的 分 布 式 Init.d， 能 够 原样 运行 任何 Linux 二 进 制 
发 布 版 本 ， 如 Tomcat、Play 等 ， 它 也 是 一 种 私有 的 PaaS， 提 供 REST 
API 服 务 ， 实 现 服务 的 发 现 ， 有 授权 和 SSL、 配 置 约束 ， 通 过 HAProxy 
实现 服务 发 现 和 负载 平衡 。 更 重要 的 是 ，Marathon 已 经 集成 了 
Docker，Mesos+Marathon 是 比较 成 熟 的 容 絮 集群 管理 解决 方案 ,已 经 
在 众多 知名 企业 的 生产 环境 中 使 用 。 图 15-3 所 示 为 Marathon 的 结构 
o 
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图 15-3 ”Marathon 结 构 


15.3.2 K8SM 


K8SM (Kubernetes-Mesos) 是 一 个 将 Kubernetes 整 合 到 Mesos 中 的 
项 目 ， 作 为 Mesos Framework， 能 够 将 Kubernetes 处 理 并 运行 在 Mesos 
之 上 ， 且 可 以 同 任意 数量 的 其 他 Mesos 框 架 (£f Marathon ` Spark ^ 
Kafka 以 及 Jenkins 等 ) 实现 同 地 协作 ， 从 而 共享 来 自 同 一 套 集群 中 的 各 
类 资源 。 


Kubemetes 是 一 个 轻 量 级 的 容 妮 管理 平台 ， 可 深度 和 灵活 地 进行 
容量 编排 ,而 Mesos 是 分 布 式 系统 内 核 ， 它 可 以 将 不 同 的 机 絮 整 合 在 
一 个 逻辑 计算 机 中 ， 有 着 非常 优秀 的 资源 调度 策略 ， 可 以 认为 Mesos 


和 Kubermnetes 的 愿景 差不多 ， 而 K8SM 则 整合 了 两 者 ，K8SM 的 架构 如 
图 15-4 所 示 。 
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图 15-4 ” K8SM 架 构 


15.4 Mesos 实 践 


15.4.1 运行 Mesos 


1. 运行 Zookeeper ° 


$ docker run -d \ 
--name zookeeper --net host \ 


mesoscloud/zookeeper :3.4.6 


2. 运行 Mesos Master 。 


$ docker run -d \ 

-e MESOS_HOSTNAME=mesos-master \ 

-e MESOS IP-«mesos-master-ip» \ 

-e MESOS QUORUM-1 \ 

-e MESOS ZK-zk://«zookeeper-ip»:2181/mesos \ 
--name mesos-master --net host \ 


mesoscloud/mesos-master:0.24.1 


3. 321] Mesos Slave ° 


$ docker run -d \ 

-e MESOS HOSTNAME=mesos-slave \ 

-e MESOS IP=<mesos-slave-ip> \ 

-e MESOS MASTER=zk://<zookeeper-ip>:2181/mesos \ 
-v /sys/fs/cgroup:/sys/fs/cgroup \ 

-v /var/run/docker.sock:/var/run/docker.sock \ 
--name mesos-slave --net host --privileged \ 


mesoscloud/mesos-slave:0.24.1 


Mesos Slave 节 点 上 需要 预先 安装 好 Docker(V1.9.1) o 


4. 待 Mesos 运 行 正 党 后， 可 以 通过 默认 5050 端 口 访问 Mesos Web 界 
面 ， 如 图 15-5 所 示 。 
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图 15-5 Mesos Web 界 面 
同时 可 以 查询 到 Mesos Slave， 如 图 15-6 所 示 。 
Slaves Y 
ov Mo cP Mem Di Registered Re-Registered 


图 15-6 ”查询 Mesos Slave 


15.4.2 ”运行 Marathon 


1. 运行 Marathon ° 


$ docker run -d \ 

-e MARATHON_HOSTNAME=marathon \ 

-e MARATHON HTTP ADDRESS-«marathon-ip» \ 

-e MARATHON MASTERzzk://«zookeeper-ip»:2181/mesos \ 
-e MARATHON ZK-zk://«zookeeper-ip»:2181/marathon \ 
--name marathon --net host \ 


mesoscloud/marathon:0.11.0 


2. Marathon 运 行 成 功 后 ， 在 Mesos 界 面 上 可 以 查询 到 Marathon 注 册 
言 轧 ， 如 网 15-7 所 示 。 同 时 可 以 通过 8080 端 口 访问 Marathon Web® 
面 ， 如 图 15-8 所 示 。 


3. 通过 调用 Marathon REST API 创 建 应 用 。 


$ curl -v \ 

-X POST -H "Content-Type: application/json" \ 
--data "@app.json" \ 
http://«marathon-ip»:8080/v2/apps 


其 中 app.json 是 应 用 的 定义 文件 ， 内 容 如 下 : 


"id": "web-app", 

"cmd": "python3 -m http.server 8080", 
"cpus": 0.5, 

"mem": 32.0, 

"instances": 1, 


"container": { 


"DOCKER", 


{ 
"python:3", 


"type": 
"docker": 

"image": 
"BRIDGE", 
[ 


{ "containerPort": 


"network": 


"portMappings": 


Active Frameworks 


ov Most Usor Name 


mar at 


Terminated Frameworks 


iov Most User 


8080, "hostPort": 


Y 


9 } 


Active Tasks CPUs Mem Max Share Reg ttered Re-Registered 
19 minutes ag 
Name Registered Unregistered 


图 15-7 


查询 Marathon 注 册 信 息 


图 15-8 Marathon Web X Tl 


在 应 用 定义 文件 中 首先 指定 了 应 用 的 ID、 资源 规格 和 运行 实例 
数 ， 在 container 属 性 中 配置 了 Docker 容 如 的 运行 参数 。 


应 用 创建 成 功 后 ，Mesos Slave 将 会 运行 起 配置 的 Docker 容 器 。 男 
外 ， 在 Marathon Web 界 面 可 以 查询 到 应 用 详情 ， 如 图 15-9 所 示 。 


/web-app 


图 15-9 查询 应 用 详情 


15.4.3 ”运行 K8SM 


1. 构建 K8SM 。 


$ git clone https://github.com/kubernetes/kubernetes 
$ export KUBERNETES CONTRIB-mesos 


$ make 


编译 成 功 后 ， 可 执行 程序 在 _output/local/go/bin 目 录 下 可 以 设置 到 
系统 环境 变量 中 : 


$ export PATH="$(pwd)/_output/local/go/bin: $PATH" 
2. 启动 K8SM ° 
设置 Mesos Master 的 地 址 : 


$ export MESOS MASTER=<mesos-master-ip>:5050 


然后 配置 文件 mesos-cloud.conf: 


$ cat <<EOF >mesos-cloud.conf 
[mesos-cloud | 
mesos-master = ${MESOS_MASTER} 


EOF 
设置 环境 变量 : 


$ export KUBERNETES MASTER IP=$(hostname -i) 


$ export KUBERNETES MASTER=http://${KUBERNETES MASTER IP}:8888 


首先 运行 Etcd: 


$ docker run -d \ 

-p 4001:4001 -p 7001:7001 \ 

--hostname $(uname -n) --name etcd \ 
quay.io/coreos/etcd:v2.0.12 \ 
--listen-client-urls http://0.0.0.0:4001 \ 


--advertise-client-urls http://0.0.0.0:4001 


Y 


然后 运行 K8SM 组 件 : 


$ km apiserver \ 

- address-$(KUBERNETES MASTER IP) \ 
--etcd-servers=http://127.0.0.1:4001 \ 

- -service-cluster-ip-range=10.10.10.0/24 \ 
--port=8888 \ 

--cloud-provider=mesos \ 

- -cloud-config-mesos-cloud.conf \ 
--secure-port=0 \ 


--v=1 >apiserver.log 2>&1 & 


$ km controller-manager \ 
--master=http://${KUBERNETES MASTER IP):8888 \ 
--cloud-provider=mesos \ 
--cloud-config=./mesos-cloud.conf \ 


--v=1 >controller.log 2>&1 & 


$ km scheduler \ 


-  address-$(KUBERNETES MASTER IP) \ 
--mesos-master-$(MESOS MASTER] \ 
--etcd-servers=http://127.0.0.1:4001 \ 
--mesos-user=root \ 
--api-servers-$(KUBERNETES MASTER IP):8888 \ 
--cluster-dns=10.10.10.10 \ 
--cluster-domain=cluster.local \ 


--v=2 >scheduler.log 2>&1 & 


3. K8SM 运 行 成 功 后 可 以 进行 查询 。 


$ kubectl -s http://${KUBERNETES MASTER IP}:8888 get services 
NAME CLUSTER_IP EXTERNAL_IP PORT(S) 
SELECTOR AGE 


k8sm-scheduler 10.10.10.132 <none> 10251/TCP 
<none> 9s 
kubernetes 10.10.10.1 «none» 443/TCP 
«none» 40s 


同时 在 Mesos Web 界 面 上 可 以 查询 到 K8SM 注 册 信 息 ， 如 图 15-10 
所 示 。 
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küsm-mester root  Kubemetes 0 1 496 MB 100 2 minutes ago 
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图 15-10 查询 K8SM 注 册 信 息 


4. 使 用 K8SM 运 行 Pod ° 


$ kubectl -s http://S[KUBERNETES MASTER IP):8888 run nginx -- 
image-nginx 


replicationcontroller "nginx" created 


当 有 Pod 创 建 后 ，K8SM Scheduler|=] Mesos ii AU, SAJSK8SM 
Scheduler 根 据 Mesos 提 供 的 资源 绑 定 Pod 到 指定 的 Mesos Slave。 这 时 
候 ，K8SM 目 动 会 在 Mesos Slave 上 运行 K8SM Executor， 其 中 包括 
Kubelet 和 Kube Proxy 组 件 。 相 应 的 ， 该 Mesos Slave 也 会 被 作为 
Kubernetes Node: 


$ kubectl -s http://${KUBERNETES MASTER IP}:8888 get node 

NAME LABELS 
STATUS AGE 

mesos-slave kubernetes.io/hostname-mesos-slave Ready 


22S 


最 后 在 Mesos Slave 上 ，K8SM 将 会 运行 起 Pod: 


$ kubectl -s http://${KUBERNETES MASTER IP):8888 get pod -- 


selector run=nginx 


NAME READY STATUS RESTARTS AGE 


nginx-1dk7d 1/1 Runing 0 im 
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经 过 作者 们 多 年 的 实践 经 验 积累 及 近 一 年 的 精心 准备 ， 本 书 终于 
与 我 们 大 家 见面 了 。 我 有 注 作 为 首 批 读者 ， 提 前 见证 和 学 习 了 在 云 时 
代 引 领 业 界 技 术 方 回 的 Kubernetes 和 Docker 的 最 新 动态 。 


从 内 容 上 讲 ， 本 书 从 一 个 开发 者 的 角度 去 理解 、 分 析 和 解决 问 
题 ， 从 基础 入 门 到 架构 原理 ， 从 运行 机 制 到 开发 源码 ， 再 从 系统 运 维 
到 应 用 实践 ， 讲 解 全 面 。 本 书 图 文 并 成 ， 内 容 丰 富 ， 由 浅 入 深 ， 对 基 
本 原理 阐述 清晰 ， 对 程序 源码 分 析 透 彻 ， 对 实践 经 验 体会 深刻 。 


我 认为 本 书 值得 推 戎 的 原因 有 以 下 几 点 。 


首先 ， 作 者 的 所 有 观点 和 经 验 ， 均 是 在 多 年 建设 、 维 护 大 型 应 用 
系统 的 过 程 中 积累 形成 的 。 例 如 ， 读 者 通过 学 习 书 中 的 Kubemetes 运 
维 指南 和 高 级 应 用 实践 案例 章节 的 内 容 ， 不 仅 可 以 直接 提高 开发 技 
能 ， 还 可 以 解决 在 实践 过 程 中 经 常 遇 到 的 各 种 关键 问题 。 书 中 的 这 些 
内 容 具有 很 高 的 借鉴 和 推广 意义 。 


其 次 ， 通 过 大 量 的 实例 操作 和 详尽 的 源码 解析 ， 本 书 可 以 帮助 读 
者 进一步 深刻 理解 Kubernetes 的 各 种 概念 。 例 如 书 中 “Java 访 问 
Kubernetes AP 的 几 种 方法 ， 读 者 参照 其 中 的 案例 ， 只 要 稍 做 修改 ， 
再 结合 实际 的 应 用 需求 ， 束 可 以 用 于 正在 开发 的 项 目 中 ， 达 到 事 半 功 


倍 的 效果 ， 有 利于 有 一 定 Java 基 础 的 专业 人 士 快 速 学 习 Kubernetes 的 各 
种 细 和 和 实践 操作 。 


再 次 ,为 了 让 初学 者 快速 入 门 ， 本 书 配 备 了 即时 在 线 交 流 工具 和 
专业 后 台 技 术 文 持 团队 。 如 果 你 在 开发 和 应 用 的 过 程 中 遇 到 各 类 相关 
问题 ， 均 可 直接 联系 该 团队 的 开发 文 持 专 家 。 


最 后 ， 我 们 可 以 看 到 ， 容 需 化 技术 已 经 成 为 计算 模型 演化 的 一 个 
开端 ，Kubernetes 作 为 谷歌 开源 的 Docker 容 器 集群 管理 技术 ， 在 这 场 新 
的 技术 革命 中 扮演 着 重要 的 角色 。Kubernetes 正 在 被 众多 知名 企业 所 
采用 ， 例 如 RedHat、VMware、CoreOS 及 腾讯 等 ， 因 此 ，Kubernetes 站 
在 了 容 颖 新 技术 变革 的 浪潮 之 赢 ， 将 具有 不 可 预 估 的 发 展 前 景 和 商业 
价值 。 


如 条 你 是 初级 程序 员 ， 那 么 你 有 必要 好 好 学 习 本 书 ; 如 采 你 正在 

IT 领 域 进行 高 级 进 阶 修炼 ， 那 你 也 有 必要 阅读 本 书 。 无 论 是 架构 师 、 

开发 者 、 运 维 人 员 ， 还 是 对 容器 技术 比较 好 奇 的 读者 ， 本 书 都 古 一 本 
不 可 多 得 的 带 你 从 入 门 同 高 级 进 阶 的 精品 书 ， 值 得 大 家 选择 1! 

初 瑞 


中 国 移动 业务 支撑 中 心 高 级 经 理 


HH 


我 不 知道 你 是 如 何 获得 这 本 书 的 ， 可 能 是 在 百度 头条 、 网 络 广 
告 、 朋 友 圈 中 昕 说 本 书后 购买 的 ， 也 可 能 是 茶 一 天 和 逛 书店 时 ， 这 本 书 
恰好 神奇 地 翻 落 书 碟 ， 出 现在 你 面前 ， 让 你 想起 一 千 多 年 前 那个 意外 
得 到 《太公 兵法 》 的 传奇 少年 ， 你 觉得 这 征 莫 莫 之 中 上 天 的 恩赐 ， 于 
征 采 断 市 走 。 不 管 怎样 ， 我 相信 多 年 以 后 ， 这 本 书 仍然 值得 你 回忆 


Kubernetes 这 个 名 字 起 源 于 古 希 腊 ， 是 舵手 的 意思 ， 所 以 它 的 
Logo 既 像 一 张 渔网 ， 又 像 一 个 罗盘 。 合 歌 采用 这 个 名 字 的 一 层 深 意 束 
是 : 既然 Docker 把 自己 定位 为 鸡 着 集装箱 在 大 海上 上 自在 邀 游 的 鲸鱼 ， 
那么 谷歌 束 要 以 Kubernetes 掌 舵 大 航海 时 代 的 话语 权 , “捕获 * 和 “ 指 
引 ” 这 条 鲸鱼 按照 < 主人” 设 定 的 路 线 这 游 ， 确 保 谷歌 倾 力 打 造 的 新 一 代 
容 絮 世界 的 宏伟 蓝图 顺利 实现 。 


虽然 Kubernetes 自 诞生 至 今 才 1 年 多 ， 其 第 一 个 正式 版 本 
Kubernetes 1.0 于 2015 年 7 月 才 发 布 ， 完 全 是 个 新 生 事物 但 其 影响 力 
EX, BAUESIT ETEIBM ^ ZG ^ WME ^ LIE ^ Intel ^ VMware ^ 
CoreOS、Docker、Mesosphere、Mirantis 等 在 内 的 众多 业界 巨头 纷纷 加 

° 红 帽 这 个 软件 虚拟 化 领域 的 领导 者 之 一 ， 在 容 句 技术 方面 已 经 完 

parr ' 合 歌 了 ， 不 仅 把 自家 的 第 三 代 Openshift 产 品 的 架 8 构 底 层 换 成 


了 Dockert+Kubernetes， 还 直接 在 其 新 一 代 容 器 操作 系统 Atomic 内 原生 
集成 了 Kubernetes。 


Kubernetes 是 第 一 个 将 “一 切 以 服务 (Service) 为 中 心 ， 一 切 围 绕 
服务 运转 ”作为 指导 思想 的 创新 型 产品 ， 它 的 功能 和 架构 设计 自始至终 
都 遵循 了 这 一 指导 思想 ， 构 建 在 Kubernetes 上 的 系统 不 仅 可 以 独立 运 
行 在 物理 机 、 虚 拟 机 集群 或 者 企业 私有 云 上 ， 也 可 以 被 托管 在 公有 云 
中 。Kubernetes 方 案 的 另 一 个 亮点 是 目 动 化 ， 在 Kubernetes 的 解决 方案 
中 ， 一 个 服务 可 以 目 我 扩展 、 目 我 诊断 ， 并 且 容 易 升 级 ， 在 收 到 服务 
扩容 的 请 求 后 ，Kubernetes 会 触发 调度 流程 ， 最 终 在 选 定 的 目标 节点 
上 启动 相应 数量 的 服务 实例 副本 ， 这 些 副 本 在 启动 成 功 后 会 自动 加 入 
负载 均衡 絮 中 并 生效 ， 整 个 过 程 无 须 额外 的 人 工 操作 。 男 外 ， 
Kubermnetes 会 定时 这 但 每 个 服务 的 所 有 实例 的 可 用 性 ， 确 保 服 务实 例 
的 数量 始终 保持 为 预期 的 数量 ， 当 它 发 现 某 个 实例 不 可 用 时 ， 会 自动 
重启 该 实例 或 者 在 其 他 方 点 重新 调度 、 运 行 一 个 新 实例 ， 这 样 ， 一 个 
复杂 的 过 程 无 顷 人 工 干 预 即 可 全 部 目 动 化 完成 。 试 想 一 下 ， 如 有 果 一 个 
包括 几 十 个 节点 且 运 行 着 几 万 个 容器 的 复杂 系统 ， 其 负载 均衡 、 故 障 
全 测 和 故障 修复 等 都 需要 人 工 介 入 进行 处 理 ， 那 将 是 多 么 难以 想象 。 


通常 我 们 会 把 Kubernetes 看 作 Docker 的 上 层 架 构 ， 就 好 像 Java 与 
J2EE 的 关系 一 样 : J2EE 是 以 Java 为 基础 的 企业 级 软件 架构 ， 而 
Kubernetes 则 以 Docker 为 基础 打造 了 一 个 云 计算 时 代 的 全 新 分 布 式 系统 
架构 。 但 Kubernetes 与 Docker 之 间 还 存在 着 更 为 复杂 的 关系， 从 表面 上 
看 ， 似 乎 Kubernetes 离 不 开 Docker， 但 实际 上 在 Kubernetes 的 架构 里 ， 
Docker 只 是 其 目前 支持 的 两 种 底层 容器 技术 之 一 ， 为 一 个 容器 技术 则 
是 Rocket， 后 者 来 源 于 CoreOS 这 个 Docker 苷 日 的 “恋人 ”所 推出 的 竞争 
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Kubermnetes 同 时 文 持 这 两 种 互相 竞争 的 容器 技术 ， 这 是 有 深刻 的 
历史 原因 的 。 人 快速 发 展 的 Docker 打 败 了 谷歌 曾经 名 噪 一 时 的 开源 容器 
技术 lImctfy， 并 迅速 风靡 世界 。 但 是 ， 作 为 一 个 已 经 对 全 球 代 公司 产 
生 重要 影响 的 拉 术 ，Docker 背 后 的 容 絮 标准 的 制定 注定 不 可 能 被 任何 
一 个 公司 私有 控制 ， 于 是 就 有 了 后 来 引发 危机 的 CoreOS 与 Docker 分 手 
事件 ， 其 导 火 索 是 CoreOS 撤 开 了 Docker， 推 出 了 与 Docker 相 对 抗 的 开 
VUE ae DH Rocket， 并 动员 一 些 知 名 开 公 司 成 立 委 员 会 来 试图 主 
导 容 器 技术 的 标准 化 ， 该 分 手 事 件 合演 钝 烈 ， 最 终 导致 CoreOS“ 傍 
上 ” 合 歌 一 起 宣布 “叛逃 *"Docker 阵 党 ， 共 同 发 起 了 基于 
CoreOS+Rocket+Kubemetes HJ #1291 H Tectonic ° 3x iE 4 AY AY Docker? = 
All Docker¥9 21 7c EG TED DockerH fg38 , AE aR BEEF, Aas ty 
术 分 裂 态 势 的 加 剧 对 所 有 牵涉 其 中 的 人 来 说 都 没有 好 处 ， 于 是 Linux 基 
金 会 出 面 调和 矛盾 ， 双 方 都 退让 一 步 ， 最 终 的 结果 是 Linux 基 金 会 于 
2015 年 6 月 宣布 成 立 开 放 容 器 技术 项 目 (Open Container Project) , @ 
歌 、CoreOS 及 Docker 都 加 入 了 了 OCP 项目 。 但 通过 查看 OCP 项 目的 成 员 
名 单 ， 你 会 发 现 Docker 在 这 个 名 单 中 只 能 算 一 个 小 角色 了 。OCP 的 成 
立 最 终结 束 了 这 场 让 无 数 人 揪心 的 “战争 ”，Docker 公 司 彼 迫 放 弃 了 日 
己 的 独家 控制 权 。 作 为 回报 ，Docker 的 容 絮 格式 被 OCP 采 纳 为 新 标准 
的 基础 ， 并 且 由 Docker 负 责 起 草 OCP 草 案 规范 的 初稿 文档 ， 当 然 这 
个 “标准 起 章 者 ”的 角色 也 不 是 那么 容易 担当 的 ，Docker 要 提交 有 目 己 的 
容 絮 执行 引擎 的 源码 作为 OCP 项 目的 启动 资源 。 


事 到 如 今 ， 我 们 再 来 回顾 当初 CoreOS 与 谷歌 的 叛逃 事件 ， 从 表面 
上 看 ， 合 歌 貌 似 古 被 诱 抛 “ 出 杷 ”的 ， 但 局 里 人 都 明日 ， 谷 歌 才 是 这 一 
系列 事件 背后 的 主 诬 ， 其 不 仅 为 当年 失败 的 Imctfy 报 了 一 稍 之 仇 ， 还 
重新 掌控 了 容器 技术 的 未 来 。 容 右 标 准 之 战 大捷 之 后 ， 合 歌 进一步 扩 
大 了 联盟 并 提高 了 目 身 影响 力 。2015 年 7 月 ， 谷 歌 正 式 宣 布 加 入 


OpenStack 阵 党， 其 目标 是 确保 Linux 容 器 及 关联 的 容器 管理 技术 
Kubernetes 能 够 被 OpenStack 生 态 圈 所 容纳 ， 并 且 成 为 OpenStack 平 台 上 
与 KVM 虚 机 一 样 的 一 等 公民 。 合 歌 加 入 OpenStack 意 味 着 对 数据 中 心 
控制 平面 的 争夺 已 经 结束 ， 以 容器 为 代表 的 应 用 形态 与 以 虚拟 化 为 代 
表 的 系统 形态 将 会 完美 融合 于 OpenStack 之 上 ， 并 与 软件 定义 网 络 和 软 
件 定义 存储 一 起 统治 下 一 代数 据 中心 。 


谷歌 凭借 着 几 十 年 大 规模 容 吉 使 用 的 丰富 经 验 ， 步 步 为 昔 ， 和 是 
祭 出 Kubernetes 这 个 神器 ， 然 后 又 掌控 了 容 事 技术 的 制定 标准 ， 最 后 
又 入 驻 OpenStack 阵 昔 全 力 将 Kubernetes 扶 上 位 ， 谷 歌 这 个 IT 界 的 领导 
者 和 创新 者 再 次 王者 归来 。 我 们 都 明白 ， 在 开 世 界 里 只 有 那些 被 大 公 
司 掌控 和 推广 的 ， 同 时 被 业界 众多 巨头 都 认可 和 文 持 的 新 技术 才能 生 
存 和 壮大 下 去 。Kubernetes 丈 是 当今 IT 界 里 符合 要 求 且 为 数 不 多 的 热门 
技术 之 一 ， 它 的 影响 力 可 能 长 达 十 年 ， 所 以 ， 我 们 每 个 人 都 有 理由 
重视 这 门 新 技术 。 


谁 能 比 别 人 领先 一 步 掌 握 新 技术 ， 谁 束 在 竞争 中 顾 得 了 移 机 。 囊 
普 中 国电 信和 解决 方案 领域 的 资深 专家 团 一 起 分 工 协作 ， 并 行 研究 ， 废 
寝 饼 食 地 合力 撰写 ， 在 短 短 的 5 个 月 内 完成 了 这 部 厚 达 500 多 页 的 
Kubermnetes 权 威 指南 。 经 过 一 年 的 高 速 发 展 ，Kubernetes 移 后 发 布 了 
1.1、1.2 和 1.3 版 本 ， 每 个 版 本 都 带 来 了 大 量 的 新 特性 ， 能 够 处 理 的 应 
用 场景 也 越 来 越 丰 富 。 本 书 遵循 从 入 门 到 精通 的 学 习 路 线 ， 全 书 共 分 
KAARET, WESTA ERRA ` RARE ` FRA ` ARR 
il GAETANO SAA, AATES S EDGE. JLF T 
Kubernetes 1.3 AA 77 77, 76386 EM TFAL S WATE 
JB SETCE > HFR - ARAR, BRETT ARITA ER 
说 ， 本 书 都 极 具 参考 价值 。 
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1.1 Kubernetes 是 什么 


Kubernetes 是 什么 ? 


首 完 ， 它 是 一 个 全 新 的 基于 容器 技术 的 分 布 式 架 构 领 完 方 案 。 这 
个 方案 虽然 还 很 狐 ， 但 它 是 合 歌 十 几 年 以 来 大 规模 应 用 容 句 技术 的 经 
验 积 于 和 升华 的 一 个 重要 成 果 。 确 切 地 说 ，Kubernetes 是 谷歌 严格 保 
密 十 几 年 的 秘密 武器 一 一 Borg 的 一 个 开源 版 本 。Borg 是 谷歌 的 一 个 久 
负 戌 名 的 内 部 使 用 的 大 规模 集群 管理 系统 ， 它 基于 容器 技术 ， 目 的 是 
实现 资源 管理 的 目 动 化 ， 以 及 器 多 个 数据 中 心 的 资源 利用 率 的 最 大 
化 。 十 几 年 来 ， 谷 歌 一 直通 过 Borg 系 统管 理 着 数量 庞大 的 应 用 程序 集 
群 。 由 于 谷歌 员工 都 签署 了 保密 协议 ， 即 便 离 职 也 不 能 泄露 Borg 的 内 
部 设计 ， 所 以 外 界 一 直 无 法 了 解 关于 它 的 更 多 信息 。 直 到 2015 年 4 月 ， 
传闻 许久 的 Borg 论 文 伴随 Kubernetes 的 高 调 宣传 被 谷歌 首次 公开 ， 大 家 
才 得 以 了 解 它 的 更 多 内 幕 。 正 是 由 于 站 在 Borg 这 个 前 蕴 的 肩膀 上 ， 吸 
取 了 Borg 过 去 十 年 间 的 经 验 与 教训 ， 所 以 Kubemetes 一 经 开源 就 一 鸣 慰 
人 ， 并 迅速 称霸 了 容 絮 技术 领域 。 


其 次 ， 如 果 我 们 的 系统 设计 遵循 了 Kubernetes 的 设计 思想 ， 那 么 
传统 系统 架构 中 那些 和 业务 没有 多 大 关系 的 确 层 代码 或 功能 模块 ， 都 


可 以 立刻 从 我 们 的 视线 中 消失 ， 我 们 不 必 再 费心 于 负载 均衡 器 的 选 型 
和 部 署 实施 问题 ， 不 必 再 考虑 引入 或 自己 开发 一 个 复杂 的 服务 治理 框 
涤 ， 不 必 再 头 疫 于 服务 监控 和 故障 处 理 模块 的 开发 。 总 之 ， 使 用 
Kubermetes 提 供 的 解决 方案 ， 我 们 不 仅 节 省 了 不 少 于 30% 的 开发 成 本 ， 
同时 可 以 将 精力 更 加 集中 于 业务 本 喘 ， 而 且 由 于 Kubernetes 提 供 了 强 
大 的 目 动 化 机 制 ， 所 以 系统 后 期 的 运 维 难度 和 运 维 成 本 大 幅度 降低 。 


然后 ，Kubernetes 是 一 个 开放 的 开发 平台 。 与 J]2EE 不 同 ， 它 不 局 
限于 任何 一 种 语言 ， 没 有 限定 任何 编程 接口 ， 所 以 不 论 是 用 Java、 
Go、C++ 还 是 用 Python 编写 的 服务 ， 都 可 以 宣 无 困难 地 映射 为 
Kubernetes 的 Service， 并 通过 标准 的 TCP 通 信 协 议 进行 交互 。 此 外 ， 由 
于 Kubernetes 平 台 对 现 有 的 编程 语言 、 编 程 框 染 、 中 间 件 没有 任何 侵 
入 性 ， 因 此 现 有 的 系统 也 很 容易 改造 升级 并 迁移 到 Kubernetes 平 台 
Es 


最 后 ，Kubernetes 是 一 个 完备 的 分 布 式 系统 文 撑 平台 。Kubernetes 
具有 完备 的 集群 管理 能 力 ， 包 括 多 层次 的 安全 防护 和 谁 入 机 制 、 多 租 
户 应 用 文 撑 能 力 、 透 明 的 服务 注册 和 服务 发 现 机 制 、 内 建 智能 负载 均 
衡器 、 强 大 的 故障 发 现 和 目 我 修复 能 力 、 服 务 滚动 升级 和 在 线 扩容 能 
力 、 可 扩展 的 资源 目 动 调度 机 制 ， 以 及 多 粒度 的 资源 配额 管理 能 
同时 ，Kubernetes 提 供 了 完善 的 管理 工具 ， 这 些 工 具 镜 盖 了 包括 开 
发 、 部 署 测 试 、 运 维 监 控 在 内 的 各 个 环 记 。 因 此 ，Kubernetes 是 一 个 
全 新 的 基于 容器 技术 的 分 布 式 架构 解决 方案 ， 并 且 是 一 个 一 站 式 的 完 
备 的 分 布 式 系统 开发 和 文 撑 平 台 。 


在 正式 开始 本 章 的 Hello world 之 旅 之 前 ， 我 们 首先 要 学 习 
Kubernetes 的 一 些 基 本 知识 ， 这 样 我 们 才能 理解 Kubernetes 提 供 的 解决 
方案 。 


¢£Kubernetes‘#, Service (ARH) 是 分 布 式 集群 架构 的 核心 ， 一 
个 Service 对 象 拥有 如 下 关键 特征 。 


。 拥 有 一 个 唯一 指定 的 名 字 (比如 mysql-server) 

。 拥 有 一 个 虚拟 IP (Cluster IP ^ Service IP 或 VIP) 和 端口 号 。 
。 能 够 提供 某 种 远程 服务 能 力 。 

。 被 映射 到 了 提供 这 种 服务 能 力 的 一 组 容器 应 用 上 。 


Service 的 服务 进程 目前 都 基于 Socket 通 信 方 式 对 外 提供 服务 ， 比 
Till Redis ` Memcache ^ MySQL ^ Web Server, 或 者 是 实现 了 某 个 具体 
业务 的 一 个 特定 的 TCP Server 进 程 。 虽 然 一 个 Service 通 常 由 多 个 相关 
的 服务 进程 来 提供 服务 ， 每 个 服务 进程 都 有 一 个 独立 的 Endpoint 
(IP+Port) 访问 点 ， 但 Kubemetes 能 够 让 我 们 通过 Service (虚拟 
Cluster IP+Service Port) 连接 到 指定 的 Service 上 。 有 了 Kubernetes 内 建 
的 透明 负载 均衡 和 故障 恢复 机 制 ， 不 管 后 端 有 多 少 服 务 进程 ， 也 不 管 
某 个 服务 进程 是 否 会 由 于 发 生 故 障 而 重新 部 署 到 其 他 机 器 ， 都 不 会 影 
啊 到 我 们 对 服务 的 正 弟 调用 。 更 重要 的 是 这 个 Service 本 寻 一 旦 创建 勤 
不 再 变化 ， 这 意味 着 ， 在 Kubernetes 集 群 中 ， 我 们 再 也 不 用 为 了 服务 
的 耳 地 址 变 来 变 去 的 问题 而 头疼 了 。 


容 需 提供 了 强大 的 隔离 功能 ， 所 以 有 必要 把 为 Service 提 供 服务 的 

这 组 进程 放 入 容器 中 进行 隔离 。 为 此 ，Kubernetes 设 计 了 Pod 对 象 ， 将 
每 个 服务 进程 包装 到 相应 的 Pod 中 ， 使 其 成 为 Pod 中 运行 的 一 个 容器 
(Container) 。 为 了 建立 Service 和 Pod 间 的 关联 关系 ，Kubernetes 首 先 
给 每 个 Pod 贴 上 一 个 标签 (Label) ， 给 运行 MySQL 的 Pod 贴 上 
name=mysql 标 签 ， 给 运行 PHP 的 Pod 贴 上 name=php 标 签 ， 然 后 给 相应 
的 Service 定 义 标签 选择 器 (Label Selector) ， 比 如 MySQL Service 的 标 
签 选 择 器 的 选择 条 件 为 name=mysql， 意 为 该 Service 要 作用 于 所 有 包含 


name-mysql Label 的 Pod 上 。 这 样 一 来 ， 融 巧妙 地 解决 了 Service 与 Pod 
的 关联 问题 。 


说 到 Pod， 我 们 这 里 先 人 简单 介绍 其 概念 。 首 先 ，Pod 运 行 在 一 个 我 
们 称 之 为 节点 (Node) 的 环境 中 ， 这 个 节点 既 可 以 是 物理 机 ， 也 可 以 
是 私有 云 或 者 公有 云 中 的 一 个 虚拟 机 ， 通 党 在 一 个 和 点 上 运行 儿 百 个 
Pod; 其 次 ， 每 个 Pod 里 运行 着 一 个 特殊 的 被 称 之 为 Pause 的 容 右 ， 其 他 
容 絮 则 为 业务 容器 ， 这 些 业 务 容 絮 共享 Pause 容 絮 的 网 络 栈 和 Volume 挂 
载 卷 ， 因 此 它们 之 间 的 通信 和 数据 交换 更 为 高 效 ， 在 设计 时 我 们 可 以 
充分 利用 这 一 特性 将 一 组 密切 相关 的 服务 进程 放 入 同一 个 Pod 中 ; 最 
后 ， 需 要 注意 的 是 ， 并 不 是 每 个 Pod 和 它 里 面 运 行 的 容器 都 能 “映射 "到 
一 个 Service 上， 只 有 那些 提供 服务 (无 论 是 对 内 还 是 对 外 ) 的 一 组 
Pod 才 会 被 “映射 ”成 一 个 服务 。 


在 集群 绾 理 方 面 ，Kubermnetes 将 集群 中 的 机 絮 划 分 为 一 个 Master 闻 
点 和 一 群 工 作 节 点 (Node) 。 其 中 ， 在 Master 节 点 上 运行 着 集群 管理 
相关 的 一 组 进程 kube-apiserver ^ kube-controller-manager 和 kube- 
scheduler， 这 些 进 程 实现 了 整个 集群 的 资源 管理 、Pod 调 度 、 掉 性 伸 
缩 、 安 全 控制 、 系 统 监控 和 纠 错 等 管理 功能 ， 并 有 旦 都 是 全 目 动 完成 
的 。Node 作 为 集群 中 的 工作 节点 ， 运 行 真正 的 应 用 程序 ， 在 Node 上 
Kubernetes 管 理 的 最 小 运行 单元 是 Pod。Node 上 运行 着 Kubernetes 的 
kubelet、kube-proxy 服 务 进程 ， 这 些 服务 进程 负责 Pod 的 创建 、 启 动 、 
监控 、 重 局 、 销 毁 ， 以 及 实现 软件 模式 的 负载 均衡 郁 。 


最 后 ， 我 们 再 来 看 看 传统 的 开 系 统 中 服务 扩容 和 服务 升级 这 两 个 
难题 ， 以 及 Kubernetes 所 提供 的 全 新 解决 思路 。 服 务 的 扩容 涉及 资源 
分 配 (选择 哪个 节点 进行 扩容 ) 、 实 例 部 署 和 局 动 等 环节 ， 在 一 个 复 


杂 的 业务 系统 中 ， 这 两 个 问题 基本 上 靠 人 工 一 步 步 操作 才 得 以 完成 ， 
费时 费力 又 难以 保证 实施 质量 。 


在 Kubernetes 集 群 中 ， 你 只 需 为 需要 扩容 的 Service 天 联 的 Pod 创 建 
一 个 Replication Controller (简称 RC) ， 则 该 Service 的 扩容 以 至 于 后 来 
的 Service 升 级 等 头疼 问题 都 迎刃而解 。 在 一 个 RC 定 义 文 件 中 包括 以 下 
3 个 关键 信息 。 


。 目 标 pod 的 定义 。 
。 目标 Pod 需 要 运行 的 副本 数量 (Replicas) 
。 要 监控 的 目标 Pod 的 标签 (Label) 


在 创建 好 RC (系统 将 自动 创建 好 Pod) 后 ，Kubernetes 会 通过 RC 
中 定义 的 Label 筷 选 出 对 应 的 Pod 实 例 并 实时 监控 其 状态 和 数量 ， 如 末 
实例 数量 少 于 定义 的 副本 数量 (Replicas) ， 则 会 根据 RC 中 定义 的 Pod 
模板 来 创建 一 个 新 的 Pod， 然 后 将 此 Pod 调 度 到 合适 的 Node 上 启动 运 
行 ， 直 到 Pod 实 例 的 数量 达到 预定 目标 。 这 个 过 程 完全 是 自动 化 的 ， 
无 顷 人 工 干 预 。 有 了 RC， 服 务 的 扩容 瓯 变 成 了 一 个 纯粹 的 简单 数字 游 
戏 了 ， 只 要 修改 RC 中 的 副本 数量 即 可 。 后 续 的 Service 升 级 也 将 通过 修 
改 RC 来 目 动 完 成 。 


以 将 在 第 2 章 介 绍 的 PHP+Redis 留 言 板 应 用 为 例 ， 只 要 为 PHP 留 言 
板 程 序 (frontend) 创建 一 个 有 3 个 副本 的 RC+Service， 为 Redis 读 写 分 
离 集群 创建 两 个 RC: FPA (redis-master) 创建 一 个 单 副 本 的 
RC+Service ， 读 节点 (redis-slaver ) 创建 一 个 有 两 个 副本 的 
RC+Service， 就 可 以 分 分 钟 完成 整个 集群 的 搭建 过 程 了 ， 是 不 是 很 简 
单 ? 


1.2 为 什么 要 用 Kubernetes 


使 用 Kubernetes 的 理由 很 多 ， 最 根本 的 一 个 理由 束 是 : I 从 来 都 是 
一 个 由 新 技术 驱动 的 行业 。 


Docker 这 个 新 兴 的 容 需 化 技术 当前 已 经 被 很 多 公司 所 采用 ， 其 从 
单机 走向 集群 已 成 为 必然 ， 而 云 计算 的 造 勃 发 展 正 在 加 速 这 一 进程 。 
Kubernetes 作 为 当前 唯一 被 业界 广泛 认可 和 看 好 的 Docker 分 布 式 系统 解 
决 方案 ， 可 以 预见 ， 在 未 来 儿 年 内 ， 会 有 大 量 的 新 系统 选择 它 ， 不 管 
这 些 系 统 是 运行 在 企业 本 地 服务 器 上 还 是 被 托管 到 公有 云 上 。 


使 用 了 Kubernetes 又 会 收获 哪些 好 处 呢 ? 


首先 ， 最 直接 的 感受 怠 是 我 们 可 以 “轻装 上 阵 ? 地 开发 复杂 系统 
了 。 以 前 动不动 天 需要 十 几 个 人 而 且 团 队 里 需要 不 少 技 术 达 人 一 起 分 
工 协作 才能 设计 实现 和 运 维 的 分 布 式 系统 ， 在 采用 Kubernetes 解 决 方 
案 之 后 ， 只 需 一 个 精 悍 的 小 团队 或 能 轻松 应 对 。 在 这 个 团队 里 ， 一 名 
架构 师 专 注 于 系统 中 “服务 组 件 * 的 提炼 ， 几 名 开发 工程 师 专 注 于 业务 
代码 的 开发 ， 一 名 系统 兼 运 维 工 程 师 负 责 Kubernetes 的 部 署 和 运 维 ， 
从 此 再 也 不 用 “996” 了 ， 这 并 不 是 因为 我 们 少 做 了 什么 ， 而 是 因为 
Kubernetes 已 经 大 有 我们 做 了 很 多 。 
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的 核心 是 将 一 个 巨大 的 单 体 应 用 分 解 为 很 多 小 的 互相 连接 的 微服 务 ， 
一 个 微服 务 背 后 可 能 有 多 个 实例 副本 在 文 撑 ， 副 本 的 数量 可 能 会 随 着 
系统 的 负荷 变化 而 进行 调整 ， 内 崩 的 负载 均衡 器 在 这 里 发 挥 了 重要 作 


FA ^ (HAR SS RS ESSE AR SS BB n] CA SP NFPA IRAP, FE 
者 可 以 目 由 选择 开发 技术 ， 这 对 于 大 规模 团队 来 说 很 有 价值 ， 另 外 每 
个 微服 务 独立 开发 、 升 级 、 扩 展 ， 因 此 系统 具备 很 高 的 稳定 性 和 快速 
XETOEIGBE7] o AW ^ ME Sf) ^ eBay ^ NetFlix SAX Ze KRKE H RR Iu] 
都 采用 了 微服 务 染 构 ， 此 次 谷歌 更 是 将 微服 务 架 构 的 基础 设施 直接 打 
包 到 Kubernetes 解 决 方案 中 ， 让 我 们 有 机 会 直接 应 用 微服 务 架 构 解 决 


复杂 业务 系统 的 架构 问题 。 


然后 ， 我 们 的 系统 可 以 随时 随地 整体 “搬迁 ”到 公有 云 上 。 

Kubernetes 最 初 的 目标 丈 是 运行 在 谷歌 目 家 的 公有 云 GCE 中 ， 未 来 会 
支持 更 多 的 公有 云 及 基于 OpenStack 的 私有 云 。 同 时 ， 在 Kubernetes 的 
架构 方案 中 ， 底 层 网 络 的 细 世 完全 被 屏蔽 ， 基 于 服务 的 Cluster IPE 
都 无 须 我 们 改变 运行 期 的 配置 文件 ， 残 能 将 系统 从 物理 机 环境 中 无 缝 
迁移 到 公有 云 中 ， 或 者 在 服务 高 峰 期 将 部 分 服务 对 应 的 Pod 副 本 放 人 入 
公有 云 中 以 提升 系统 的 吞吐 量 ， 不 仅 节 省 了 公司 的 硬件 投入 ， 还 大 大 
改善 了 客户 体验 。 我 们 所 熟知 的 铁道 部 的 12306 购 票 系统 ， 在 春节 高 峰 
期 惑 租用 了 阿里 云 进行 分 流 。 


最 后 ，Kubernetes 系 统 染 构 具 备 了 超 强 的 横向 扩容 能 力 。 对 于 互 
联网 公司 来 说 ， 用 户 规 模 就 等 价 于 资产 ， 谁 拥有 更 多 的 用 户 ， 谁 就 能 
在 竞争 中 胜出 ， 因 此 超 强 的 横向 扩容 能 力 是 互联 网 业务 系统 的 关键 指 
标 之 一 。 不 用 修改 代码 ， 一 个 Kubernetes 集 群 即 可 从 只 包含 几 个 Node 
的 小 集群 平滑 扩展 到 拥有 上 百 个 Node 的 大 规模 集群 ， 我 们 利用 
Kubernetes 提 供 的 工具 ， 甚 至 可 以 在 线 完成 集群 扩容 。 只 要 我 们 的 微 
服务 设计 得 好 ， 结 合 硬 件 或 者 公有 云 资 源 的 线性 增加 ， 系 统 束 能 够 承 
受 大 量 用 户 并 发 访问 所 带 来 的 巨大 压力 。 


1.3 从 一 个 简单 的 例子 开始 


考虑 到 本 书 第 1 版 中 的 PHP+Redis 留 言 板 的 Hello Word FX FÉ 
大 多 数 刚 接触 Kubernetes 的 人 来 说 比较 复杂 ， 难 以 顺利 上 手 和 实践 ， 
所 以 我 们 在 此 将 这 个 例子 玲 换 成 一 个 简单 得 多 的 Java Web 应 用 ， 可 以 
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此 Java Web 应 用 的 结构 比较 简单 ， 是 一 个 运行 在 Tomcat 里 的 Web 
App， 如 图 1.1 所 示 ，JSP 页 面 通过 JDBC 直 接 访问 MySQL 数 据 库 并 展示 
数据 。 为 了 演示 和 简化 的 目的 ， 只 要 程序 正确 连接 到 了 数据 库 上 ， 它 
就 会 自动 完成 对 应 的 Table 的 创建 与 初始 化 数据 的 准备 工作 。 所 以 ， 当 
我 们 通过 浏览 器 访问 此 应 用 的 时 候 ， 就 会 显示 一 个 表格 的 页 面 ， 数 据 
则 来 自 数据 库 。 


Java Web App 


decker 


1.1 Java Web 应 用 的 架构 组 成 


此 应 用 需要 启动 两 个 容器 : Web App 容 器 和 MySQL 容 器 ， 并 且 
Web App 容 器 需要 访问 MySQL 容 絮 。 在 Docker 时 代 ， 假 设 我 们 在 一 个 


宿主 机 上 启动 了 这 两 个 容器 ， 则 我 们 需要 把 MySQL 容 器 的 卫 地 址 通过 
环境 变量 的 方式 注入 Web App 容 器 里 ; 同时 ， 需 要 将 WebApp 容 器 的 
8080 端 口 映 射 到 宿主 机 的 8080 端 口 ， 以 便 能 在 外 部 访问 。 在 本 章 的 这 
个 例子 里 ， 我 们 看 看 在 Kubernetes 时 代 是 如 何 完成 这 个 目标 的 。 


1.3.1 ”环境 准备 


首先 ， 我 们 开始 准备 Kubernetes 的 安装 和 相关 镜像 下 载 ， 本 书 建 
议 采 用 VirtualBox 或 者 VMwareWorkstation 在 本 机 虚拟 一 个 64 位 的 
CentOS 7 虚拟 机 作为 学 习 环 境 ， 虚 拟 机 采用 NAT 的 网 络 模式 以 便 能 够 
连接 外 网 ， 然 后 按照 以 下 步骤 快速 安装 Kubernetes。 


(1) 关闭 CentOS 目 这 的 防火 墙 服务 : 


# systemctl disable firewalld 


# systemctl stop firewalld 


(2) 安装 etcd 和 Kubernetes 软 件 〈 会 自动 安装 Docker 软 件 ) : 


#yum install -y etcd kubernetes 


(3) 安装 好 软件 后 ， 修 改 两 个 配置 文件 〈 其 他 配置 文件 使 用 系统 
默认 的 配置 参数 即 可 ) 


。 Docker 配 置 文件 为 /etc/sysconfig/docker， 其 中 OPTIONS 的 内 容 设 
PL: 


OPTIONS-'--selinux-enabled-false --insecure-registry 


gcr.io' 


e Kubernetes apiserver 配置 文件 为 /etc/kubernetes/apiserver ， 把 -- 
admission control 2 3X $F HJServiceAccountlll KR ° 


(4) 按 顺序 启动 所 有 的 服务 : 


#systemctl 
#systemctl 
#systemctl 
#systemctl 
#systemctl 
#systemctl 


#systemctl 


start 
start 
start 
start 
start 
start 


start 


etcd 

docker 

kube-apiserver 
kube-controller -manager 
kube-scheduler 

kubelet 


kube-proxy 
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接 下 来 ， 我 们 可 以 在 这 个 单机 版 的 Kubernetes 集 群 中 上 手 练习 


[fe 
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https://hub.docker.com/u/kubeguide/ ° 


1.3.2 ”启动 MySQL 服 务 


首先 为 MySQL 服 务 创建 一 个 RC 定 义 文件 : mysql-rc.yaml， 下 面 给 
出 了 该 文件 的 完整 内 容 和 解释 ， 如 图 1.2 所 示 。 


apiVersion: vl 


kind: ReplicationController 一 一 一 一 一 一 副本 控制 器 RC 
metadata: 
name: mysql 一 一 一 一 一 一 RC 的 名 称 ， 全 局 唯一 
spec: 
replicas: 1 — Pod 副本 期 待 数量 
selector: 
app: mysql 一 一 一 一 一 一 符合 目标 的 Pod 拥有 此 标签 
template: 一 一 一 一 一 根据 此 模板 创建 Pod 的 副本 实例》 
metadata: 
labels: 
app: mysql 一 一 一 一 一 一 Pod 副本 拥有 的 标签 ， 对 应 RC 的 Selector 
spec: 
containers: — Pod 内 容器 的 定义 部 分 
- name: mysql 一 一 一 一 一 容器 的 名 称 
image: mysql 一 一 一 一 一 一 容器 对 应 的 Docker Image 
ports: 
- containerPort: 3306 一 一 一 一 一 一 容器 暴露 的 端口 号 
env: 一 一 一 一 一 注入 到 容器 内 的 环境 变量 


- name: MYSQL ROOT PASSWORD 
value: "123456" 


12 ”RC 的 定义 和 解说 图 


yaml 定 义 文件 中 的 kind 属 性 ， 用 来 表明 此 资源 对 象 的 类 型 ， 比 如 
这 里 的 值 为 “ReplicationController”， 表 示 这 是 一 个 RC; spec— DH Pe 
RC 的 相关 属性 定义 ， 比 如 spec.selector 是 RC 的 Pod 标 签 (Label) 选择 
器 ， 即 监控 和 管理 拥有 这 些 标签 的 Pod 实 例 ， 确 保 当 前 集群 上 始终 
且 仅 有 replicas 个 Pod 实 例 在 运行 ， 这 里 我 们 设置 replicas=1 表 示 只 能 运 
行 一 个 MySQL Pod 实 例 。 当 集群 中 运行 的 Pod 数 量 小 于 replicas 时 ，RC 
会 根据 spec.template 一 世 中 定义 的 Pod 模 板 来 生成 一 个 新 的 Pod 实 例 ， 


spec.template.metadata.labels 指 定 了 该 Pod 的 标签 ， 需 要 特别 注意 的 是 : 
这 里 的 labels 必 须 人 匹配 之 前 的 spec.selector， 否 则 此 RC 每 次 创建 了 一 个 
无 法 匹配 Label 的 Pod， 就 会 不 集 地 党 试 创建 狐 的 Pod， 最 终 陷入 “只 为 
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Kubernetes 集 群 中 ， 我 们 在 Master 点 执行 命令 : 


# kubectl create -f mysql-rc.yaml 


replicationcontroller "mysql" created 


接 下 来 ， 我 们 用 kubectl 命 令 查 看 刚刚 创建 的 RC: 


# kubectl get rc 
NAME DESTRED CURRENT AGE 


mysql 1 1 7m 


查看 Pod 的 创建 情况 时 ， 可 以 运行 下 面 的 命令 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 
mysql-c95jc 1/1 Running 0 
9m 


我 们 看 到 一 个 名 为 mysql-xxxxx 的 Pod 实 例 ， 这 是 Kubernetes 根 据 
mysql 这 个 RC 的 定义 目 动 创 建 的 Pod。 由 于 Pod 的 调度 和 创建 需要 花费 
一 定 的 时 间 ， 比 如 需要 一 定 的 时 间 来 确定 调度 到 哪个 太 点 上 ， 以 及 下 
载 Pod 里 容器 的 镜像 需要 一 段 时 间 ， 所 以 一 开始 我 们 看 到 Pod 的 状态 将 


显示 为 Pending。 当 Pod 成 功 创建 完成 以 后 ， 状 态 最 终 会 被 更 新 为 


Running ° 


我 们 通过 docker ps 指令 查看 正在 运行 的 容器 ， 发 现 提 供 MySQL 服 
务 的 Pod 容 器 已 经 创建 并 正常 运行 了 ， 此 外 ， 你 会 发 现 MySQL Pod 对 
应 的 容器 还 多 创建 了 一 个 来 自 谷 歌 的 pause 容 器 ， 这 就 是 Pod 的 “ 根 容 
器 ”， 详 见 1.4.3 节 的 说 明 。 


# docker ps |grep mysql 
72ca992535b4 mysql 
"docker-entrypoint.sh" 12 minutes ago Up 12 minutes 
k8s mysql.86dc506e mysql-c95jc default 511d6705-5051-11e6- 
a9d8 -000c29ed42c1_9f89d0b4 


76c1790aad27 gcr.io/google containers/pause- 
amd64:3.0 "/pause" 12 minutes 
ago Up 12 minutes 


k8s POD.16b20365 mysql-c95jc default 511d6705-5051-11e6- 
a9d8-000c29ed42c1_28520aba 


最 后 ， 我 们 创建 一 个 与 之 关联 的 Kubernetes Service———MySQLRS 
定义 文件 (文件 名 为 mysql-svc.yaml) ， 完 整 的 内 容 和 解释 如 图 1.3 所 
示 o 


apiVersion: vl 


kind: Service — — ——— 表明 是 Kubernetes Service 
metadata: 
name: mysql Service 的 全 局 唯一 名 称 
spec: 
ports: 
- port: 3306 一 一 一 一 一 Service 提供 服务 的 端口 号 
selector: Service 对 应 的 Pod 拥有 这 里 定义 的 标签 


app: mysql 


图 1.3 Service 的 定义 和 解说 图 


其 中 ，metadata.name 是 Service 的 服务 名 (ServiceName) ; port/& 
性 则 定义 了 Service 的 虚 端 口 ; spec.selector 确 定 了 哪些 Pod 副 本 (SE 
AD 对 应 到 本 服务 。 类 似 地 ， 我 们 通过 kubect create 命 令 创建 Service 
对 象 。 


运行 kubectl 命 令 ， 创 建 service: 


# kubectl create -f mysql-svc.yaml 


service "mysql" created 


运行 kubectl 命 令 ， 可 以 查看 到 刚刚 创建 的 service: 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 


mysql 169.169.253.143 «none» 3306/TCP 


注意 到 MySQL 服 务 被 分 配 了 一 个 值 为 169.169.253.143 的 ClusterIP 
地 址 ， 这 是 一 个 虚 地 址 ， 随 后 ，Kubernetes 集 群 中 其 他 新 创建 的 Pod 束 
可 以 通过 Service 的 ClusterIP+ 端 口号 6379 来 连接 和 访问 它 了 。 


在 通常 情况 下 ，ClusterIP 是 在 Service 创 建 后 由 Kubernetes 系 统 目 动 
分 配 的 ， 其 他 Pod 无 法 预先 知道 某 个 Service 的 ClusterIP 地 址 ， 因 此 需要 
一 个 服务 发 现 机 制 来 找到 这 个 服务 。 为 此 ， 最 初 的 时 候 ，Kubernetes 
巧妙 地 使 用 了 Linux 环 境 变 量 (Environment Variable) 来 解决 这 个 问 


题 ， 后 面 会 详细 说 明 其 机 制 。 现 在 我 们 只 需 知 道 ， 根 据 Service 的 唯一 
名 字 ， 容 需 可 以 从 环境 变量 中 获取 到 Service 对 应 的 Cluster 了 地 址 和 端 
口 ， 从 而 发 起 TCP/IP 连 接 请 求 了 。 


1.8.3 JB Tomcat Hj 


上 面 我 们 定义 和 局 动 了 MySQL 服 务 ， 接 下 来 我 们 采用 同样 的 步 
骤 ， 完 成 Tomcat 应 用 的 局 动 过 程 。 首 先 ， 创 建 对 应 的 RC 文 件 myweb- 
rc.yaml， 内 容 如 下 : 


kind: ReplicationController 
metadata: 
name: myweb 
spec: 
replicas: 5 
selector: 
app: myweb 
template: 
metadata: 
labels: 
app: myweb 
spec: 
containers: 
- name: myweb 
image: kubeguide/tomcat-app:vi 
ports: 
- containerPort: 8080 


env: 


- name: MYSQL_SERVICE_HOST 
value: 'mysql' 
- name: MYSQL_SERVICE_PORT 


value: '3306' 


x 2] 上面 RC 对 应 的 Tomcat 容器 里 引用 了 
MYSQL SERVICE HOST-mysqUXx HASE, Ti “mysql” ta fé 
们 之 前 定义 的 MySQL 服 务 的 服务 名 ， 运 行 下 面 的 命令 ， 完 成 RC 的 创 
建 和 验证 工作 : 


Zkubectl create -f myweb-rc.yaml 


replicationcontroller "myweb" created 


#kubectl get pods 


NAME READY STATUS RESTARTS AGE 
mysql-c95jc 1/1 Running 0 2h 
myweb - g9pmm 1/1 Running 0 3S 


最 后 ， 创 建 对 应 的 Service。 以 下 是 完整 的 yaml 定 义 文 件 (myweb- 


svc.yaml) 


apiVersion: v1 
kind: Service 
metadata: 

name: myweb 
spec: 


type: NodePort 


ports: 
- port: 8080 
nodePort: 30001 
selector: 


app: myweb 


注意 type=NodePort 和 nodePort=30001 的 两 个 属性 ， 表 明 此 Service 
AIA T NodePortm FAESA EN ABS 在 Kubernetes 集 群 之 外 ， 比 如 在 
本 机 的 浏览 器 里 ， 可 以 通过 30001 这 个 端口 访问 myweb (对 应 到 8080 的 
虚 端 口上 ) e 


运行 kubectl create 命 令 进行 创建 : 


# kubectl create -f myweb-svc.yaml 
You have exposed your service on an external port on 
all nodes in your 
cluster. If you want to expose this service to the 
external internet, you may 
need to set up firewall rules for the service port(s) 
(tcp:30001) to serve traffic. 
See http://releases.k8s.io/release-1.3/docs/user - 
guide/services-firewalls.md for more details. 


service "myweb" created 


KITE EHA Qus 意思 是 需要 把 30001 这 个 端口 在 防火 墙 
上 打开 ， 以 便 外 部 的 访问 能 罕 过 防火 墙 。 


运行 kubectl 命 令 ， 查 看 创建 的 Service: 


# kubectl get services 


NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
AGE 

mysql 169.169.253.143 «none» 3306/TCP 
44m 

myweb 169.169.149.215 «nodes» 8080/TCP 
4m 

kubernetes 169.169.0.1 «none» 

443/TCP 16d 


至 此 ， 我 们 的 第 1 个 Kubermetes 例 子 搭建 完成 了 ， 在 下 一 节 中 我 们 
验证 结果 。 


1.3.4 YM Ps V In] P DR 


经 过 上 面 的 几 个 步骤 ， 我 们 终于 成 功 实现 了 Kubernetes 上 第 1 个 例 
子 的 部 署 搭 建 工作 。 现 在 一 起 来 见证 成 果 吧 ， 在 你 的 笔记 本 上 打开 浏 


Wy HE 


bias, "A http://zf LIP: 30001/demo/ ° 


比如 虚 机 IP 为 192.168.18.131 (可 以 通过 #ip a 命 令 进行 查询 ) , E 
浏览 器 里 输入 地 址 http://192.168.18.131: 30001/demo/ 后 ， 看 到 了 如 
1.4 所 示 的 网 页 界面 ， 那 么 恭喜 你 ， 之 前 的 努力 没有 和 白费， 顺利 韶关 成 
功 ! 


Congratulations!! 


Add 


Name Level (Score) 
google | 100 
docker 100 
100 


PE 100 
our team | 100 
me | 100 


+ 
2 


1.4 ”通过 浏览 器 访问 Tomcat 应 用 


如 果 看 不 到 这 个 网 页 ， 那 么 可 能 有 几 个 原因 : 比如 防火 墙 的 问 
题 ， 无 法 访问 30001 端 口 ， 或 者 因为 你 是 通过 代理 上 网 的 ， 浏 览 器 错 把 
虚拟 机 的 卫 地 址 当成 远程 地 址 了 。 可 以 在 虚拟 机 上 直接 运行 cunl 
localhost: 30001 来 验证 此 端口 是 否 能 被 访问 ， 如 果 还 是 不 能 访问 ， 屠 
和 这 肯定 不 是 机 器 的 问题 …… 


接 下 来 可 以 党 试 单 击 “Add...” 按 钮 添加 一 条 记录 并 提交 ， 如 网 1.5 
所 示 ， 提 区 以 后 ， 数 据 驶 被 写 入 MySQL 数 据 库 中 了 。 


至 此 ， 我 们 终于 完成 了 Kubernetes 上 的 Tomcat 例 子 ， 这 个 例子 并 
不 是 很 复杂 。 我 们 也 看 到 ， 相 对 于 传统 的 分 布 式 应 用 的 部 署 方式 ， 在 
Kubermetes 之 上 我 们 仅仅 通过 一 些 很 容易 理解 的 配置 文件 和 相关 的 简 
单 命 令 束 完成 了 对 整个 集群 的 部 署 ， 这 让 我 们 惊 这 于 Kubernetes 的 创 
BUNC, ° 


Please input your info 


Your name: |Me| 


Your Level: 100 


Cancel | | Submit | 


图 1.5 在 留言 板 网 页 添加 新 的 留言 


下 一 节 ， 我 们 将 开始 对 Kubernetes 中 的 基本 概念 和 术语 进行 全 面 
学 习 ， 在 这 之 前 ， 读 者 可 以 继续 人 研究 下 这 个 例子 里 的 一 些 拓展 内 容 ， 
如 下 所 述 。 


e RRC ` Service XFIRE ° 

。 熟悉 kubectl 的 子 命令 。 

。 手 工作 止 某 个 Service 对 应 的 容 事 进程 ， 然 后 观察 有 什么 现象 发 
Æ o 

。 修改 RC 文件 ， 改 变 副本 数量 ， 重 新 发 布 ， 观 察 结 采 。 


1.4 Kubernetes 基 本 概念 和 术语 


Kubernetes 中 的 大 部 分 概念 如 Node、 了 Pod、ReplicationController ^ 
Service 等 都 可 以 看 作 一 种 “资源 对 象 ?”” 几乎 所 有 的 资源 对 象 都 可 以 通 
过 Kubemetes 提 供 的 kubectl 工 具 (或 者 API 编 程 调用 ) 执行 增 、 删 、 
改 、 查 等 操作 并 将 其 保存 在 etcd 中 持久 化 存储 。 从 这 个 角度 来 看 ， 
Kubernetes 其 实 是 一 个 高 度 自动 化 的 资源 控制 系统 ， 它 通过 跟 中 对比 
etcd 库 里 保存 的 “资源 期 望 状态 ”与 当前 环境 中 的 “实际 资源 状态 ”的 差异 
来 实现 自动 控制 和 上 自动 纠 错 的 高 级 功能 。 


1.4.1 Master 


Kubermnetes 里 的 Master 指 的 是 集群 控制 入 点 ， 每 个 Kubernetes 集 群 
里 需要 有 一 个 Master 节 点 来 负责 整个 集群 的 管理 和 控制 ， 基 本 上 
Kubernetes 所 有 的 控制 命令 都 是 发 给 它 ， 它 来 负责 具体 的 执行 过 程 ， 
我 们 后 面 所 有 执行 的 命令 基本 都 是 在 Master 玉 点 上 运行 的 。Master 闻 
点 通常 会 占据 一 个 独立 的 X86 服务 器 (或 者 一 个 虚拟 机 ) ， 一 个 主要 
的 原因 是 它 太 重 要 了 ， 它 是 整个 集群 的 “首脑 ?"， 如 采 它 宕 机 或 者 不 可 
用 ， 那 么 我 们 所 有 的 控制 命令 都 将 失效 。 


Master 世 点 上 运行 着 以 下 一 组 关键 进程 。 


Kubernetes API Server (kube-apiserver) ， 提 供 了 HTTP Rest 接 口 
的 关键 服务 进程 ， 是 Kubernetes 里 所 有 资源 的 增 、 删 、 改 、 查 等 
操作 的 唯一 入 口 ， 也 是 集群 控制 的 入 口 进程 。 

Kubernetes Controller Manager ( kube-controller-manager ) 
Kubernetes 里 所 有 资源 对 象 的 目 动 化 控制 中 心 ， 可 以 理解 为 资源 
对 象 的 “大 总 管 ”。 

Kubernetes Scheduler (kube- ol ， 人 负责 资源 调度 (Pod 调 
度 ) 的 进程 ， 相 当 于 公交 公司 的 “调度 


其 实 Master 玉 点 上 往往 还 局 动 了 一 个 etcd Server 进程 ， 因 为 
Kubernetes 里 的 所 有 资源 对 象 的 数据 全 部 是 保存 在 etcd 中 的 。 


1.4.2 Node 


be f Master, KubernetesS2## rP B5 AHA Lari ANode P s, TERS 
早 的 版 本 中 也 被 称 为 Minion。 5EjMaster— T£, Node i Qa D zé— & 
理 主机 ， 也 可 以 是 一 台 虚 拟 机 。Node 广 点 才 是 Kubermetes 集 群 中 的 工 
作 负 载 节 点 ， 每 个 Node 都 会 被 Master 分 配 一 些 工作 负载 (Docker 容 
av) ， 当 某 个 Node 宕 机 时 ， 其 上 的 工作 负载 会 被 Master 上 自动 转移 到 其 
fii m REE ° 


& Node T 5i E5118 DA P — 8E HEURE © 


e kubelet: 负责 Pod 对 应 的 容器 的 创建 、 局 停 等 任务 ， 同 时 与 Master 
节点 密切 协作 ， 实 现 集群 管理 的 基本 功能 。 

。 kube-proxy: 实现 Kubernetes Service 的 通信 与 负载 均衡 机 制 的 重要 
组 件 。 

e Docker Engine (docker) : Docker 引 擎 ， 负 责 本 机 的 容 右 创建 和 
管理 工作 。 


Node 市 点 可 以 在 运行 期 间 动 态 增 加 到 Kubernetes 集 群 中 ， 前 提 是 
这 个 节点 上 已 经 正确 安装 、 配 置 和 启动 了 上 述 关 键 进程 ， 在 默认 情况 
下 kubelet 会 癌 Master 注 册 目 己 ， 这 也 是 Kubernetes 推 荐 的 Node 管 理 方 
式 。 一 旦 Node 被 纳入 集群 管理 范围 ，kubelet 进 程 束 会 定时 间 Master-T 
点 汇报 目 喘 的 情报 ， 例 如 操作 系统 、Docker 版 本 、 机 器 的 CPU 和 内 存 
情况 ， 以 及 之 前 有 哪些 Pod 在 运行 等 ， 这 样 Master 可 以 获知 每 个 Node 的 
资源 使 用 情况 ， 并 实现 高 效 均衡 的 资源 调度 策略 。 而 某 个 Node 超 过 指 


定时 间 不 上 报信 息 时 ， 会 被 Master 判 定 为 "“ 失 联 ”，Node 的 状态 被 标记 
为 不 可 用 (Not Ready) ， 随 后 Master 会 触发 “工作 负载 大 转移 ”的 自动 
流程 。 


我 们 可 以 执行 下 述 命令 查看 集群 中 有 多 少 个 Node: 


# kubectl get nodes 
NAME STATUS AGE 


kubernetes-minioni Ready 2d 


太后， 通过 kubectl describe node«node name> & @ X: T Nodellj 


~ 


$ kubectl describe node kubernetes-minioni 
Name : k8s-node-1 
Labels: beta. kubernetes.io/arch=amd64 


beta. kubernetes.io/os=linux 
kubernetes.io/hostname-k8s-node-1 
Taints: «none» 


CreationTimestamp: Wed, 06 Jul 2016 11:46:41 +0800 


Phase: 

Conditions: 
Type Status LastHeartbeatTime 
XXXX OutOfDisk False Sat, 09 Jul 2016 
08:17:39 +0800 Wed 


MemoryPressure False Sat, 09 Jul 2016 08:17:39 


+0800 Wed aa. 


Ready True Sat, 09 Jul 2016 
08:17:39 +0800 Wed aaa, 
Addresses: 192.168.18.131,192.168.18.131 
Capacity: 
alpha. kubernetes.io0/nvidia-gpu: 0 
Cpu: 4 
memory: 1868692Ki 
pods: 110 
Allocatable: 
alpha.kubernetes.io/nvidia-gpu: 0 
Cpu: 4 
memory: 1868692Ki 
pods: 110 


System Info: 


Machine ID: 
6e4e2af 2afeb42b9aac47d866aa56cad 
System UUID: 564D63D3 - 9664-3393 - 
A3DC -9CD424ED42C1 
Boot ID: bOc34f9F -76ab-478e-9771- 
bd4fe6e98880 
Kernel Version: 3.10.0-327.22.2.e17.x86_64 
OS Image: CentOS Linux 7 (Core) 
Operating System: linux 
Architecture: amd64 
Container Runtime Version: docker://1.11.2 


Kubelet Version: v1.3.0 


Kube-Proxy Version: v1.3.0 


ExternalID: k8s -node-1 
Non-terminated Pods: (1 in total) 
Namespace Name 
CPU Requests CPU Limits Memory xxx 
kube-system kube-dns-vi1-wxdhf 
310m (796) 310m (796) 170Mi (9%) 


Allocated resources: 
(Total limits may be over 100 percent, i.e., 

overcommitted. More info: 
CPU Requests CPU Limits Memory 


Requests Memory Limits 


310m (7%) 310m (7%) 170Mi (9%) 170Mi (9%) 


No events. 


上 述 命令 展示 了 Node 的 如 下 关键 信息 。 


Node 基 本 信息 : 名 称 、 标 签 、 创 建 时 间 等 。 

Node 当 前 的 运行 状态 ，Node 局 动 以 后 会 做 一 系列 的 目 检 工 作 ， 比 
如 磁 强 是 否 满 了 ， 如 果 满 了 就 标注 OutOfDisk=True， 人 否则 继续 检 
查 内 存 是 否 不 足 (MemoryPressure=True) ， 最 后 一 切 正 常 ， 就 切 
me A (Ready=True) ， 这 种 情况 表示 Node 处 于 健康 状 
态 ， 可 以 在 其 上 创建 新 的 Pod 。 


Node 的 主机 地 址 与 主机 名 。 

Node 上 的 资源 总 量 : 摘 述 Node 可 用 的 系统 资源 ， 包 括 CPU、 内 存 
数量 、 最 大 可 调度 Pod 数 量 等 ， 注 意 到 目前 Kubernetes 已 经 实验 性 
地 支持 GPU 资 源 分 配 了 (alpha.kubernetes.io/nvidia-gpu-0) 

Node 可 分 配 资源 量 : 摘 述 Node 当 前 可 用 于 分 配 的 资源 量 。 

主机 系统 信息 : 包括 主机 的 唯一 标识 UUID、Linux kernel 版 本 
号 、 操 作 系 统 类 型 与 版 本 、Kubernetes 有 版 本 号 、kubelet £ kube- 
proxy 的 版 本 号 等 。 

当前 正在 运行 的 Pod 列 表 概 要 信息 。 

已 分 配 的 资源 使 用 概要 信息 ， 例 如 资源 申请 的 最 低 、 最 大 允许 使 
用 量 占 系统 总 量 的 百分比 。 

Node 相 关 的 Event 信 息 。 


1.4.3 Pod 


Pod 是 Kubernetes 的 最 重要 也 最 基本 的 概念 ， 如 图 1.6 所 示 是 Pod 的 
组 成 示意 图 ， 我 们 看 到 每 个 Pod 都 有 一 个 特殊 的 被 称 为 “ 根 容 絮 ”的 
Pause 容 器 。Pause 容 右 对 应 的 镜像 属于 Kubernetes 平 台 的 一 部 分 ， 除 了 
Pause 容 器 ， 每 个 Pod 还 包含 一 个 或 多 个 紧密 相关 的 用 户 业 务 容 器 。 


Pod 


Pause 


gcrio/google_containers/pause-amd64 


user conainter 1 
xxxlmage 


user conainter 2 


xxxlmage 


user conainter N 
xxxlmage 


图 1.6 ”Pod 的 组 成 与 容器 的 关系 


为 什么 Kubernetes 会 设计 出 一 个 全 新 的 Pod 的 概念 并 且 Pod 有 这 样 
特殊 的 组 成 结构 ? 


原因 之 一 : 在 一 组 容 带 作为 一 个 单元 的 情况 下 ， 我 们 难以 对 “ 整 
体 ” 人 简单 地 进行 判断 及 有 效 地 进行 行动 。 比 如， 一 个 容器 死亡 了 ， 此 时 
算是 整体 死亡 么 ? 是 N/M 的 死亡 率 么 ? 引入 业务 无 关 并 且 不 易 死 亡 的 
Pause 容 右 作 为 Pod 的 根 容器 ， 以 它 的 状态 代表 整个 容 右 组 的 状态 ， 束 
人 简单、 巧妙 地 解决 了 这 个 难题 。 


原因 之 二 : Pod 里 的 多 个 业务 容器 共享 Pause 容 絮 的 IP， 共 享 Pause 
容 姨 挂 接 的 Volume， 这 样 既 简 化 了 密切 关联 的 业务 容器 之 间 的 通信 问 
题 ， 也 很 好 地 解决 了 它们 之 间 的 文件 共享 问题 。 


Kubemetes 为 每 个 Pod 都 分 配 了 唯一 的 IP 地 址 ， 称 之 为 Pod IP, 一 
个 Pod 里 的 多 个 容器 共享 Pod IP 地 址 。Kubernetes 要 求 故 层 网 络 支持 集 
群 内 任意 两 个 Pod 之 间 的 TCP/IP 直 接 通 信 ， 这 通常 采用 虚拟 二 层 网 络 
技术 来 实现 ， 例 如 Flannel、Openvswitch 等 ， 因 此 我 们 需要 牢记 一 点 : 
在 Kubernetes 里 ， 一 个 Pod 里 的 容器 与 另外 主机 上 的 Pod 容 器 能 够 直接 
通信 。 


Pod 其 实 有 两 种 类 型 : 普通 的 Pod 及 静态 Pod (static Pod) ， 后 者 
比较 特殊 ， 它 并 不 存放 在 Kubernetes 的 etcd 存 储 里 ， 而 是 存放 在 某 个 具 
体 的 Node 上 的 一 个 具体 文件 中 ， 并 且 只 在 此 Node 上 启动 运行 。 而 普通 
的 Pod 一 旦 被 创建 ， 就 会 被 放 入 到 etcd 中 存储 ， 随 后 会 被 Kubernetes 
Master 调 度 到 某 个 具体 的 Node 上 并 进行 绑 定 (Binding) ， 随 后 该 Pod 
被 对 应 的 Node 上 的 kubelet 进 程 实例 化 成 一 组 相关 的 Docker 容 需 并 局 动 
起 来 。 在 默认 情况 下 ， 当 Pod 里 的 某 个 容 需 停止 时 ，Kubernetes 会 目 动 
今 测 到 这 个 问题 并 且 重 新 启动 这 个 Pod (重启 Pod 里 的 所 有 容器 ) ， 如 
末 Pod 所 在 的 Node 宕 机 ， 则 会 将 这 个 Node 上 的 所 有 Pod 重 新 调度 到 其 他 
节点 上 。Pod、 容 器 与 Node 的 关系 如 图 1.7 所 示 。 


| Master 


se) = 

X rod 2 

Node2 | | | .|Node3 
Pod - 容器 


图 1.7 ”Pod、 容 器 与 Node 的 关系 


Kubernetes 里 的 所 有 资源 对 象 都 可 以 采用 yaml 或 者 JSON 格 式 的 文 
件 来 定义 或 描述 ， 下 面 是 我 们 在 之 前 Hello World 例 子 里 用 到 的 myweb 
这 个 Pod 的 资源 定义 文件 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: myweb 
labels: 
name: myweb 
spec: 
containers: 
- name: myweb 
image: kubeguide/tomcat -app: v1 


ports: 


- containerPort: 8080 

env: 

- name: MYSQL_SERVICE_HOST 
value: 'mysql' 

- name: MYSQL_SERVICE_PORT 


value: '3306' 


Kind 为 Pod 表 明 这 是 一 个 Pod 的 定义 ，metadata 里 的 name 属 性 为 Pod 
的 名 字 ，metadata 里 还 能 定义 资源 对 象 的 标签 (Label) ， 这 里 声明 
myweb 拥 有 一 个 name=myweb 的 标签 (Label) 。Pod 里 所 包含 的 容器 组 
的 定义 则 在 spec 一 节 中 声明 ， 这 里 定义 了 一 个 名 字 为 myweb、 对 应 镜 
像 为 kubeguide/tomcat-app : v1 Bj Aw, HAA RIEA TAA 
MYSQL_SERVICE_HOST=‘mysql’ 和 
MYSQL_SERVICE_PORT=‘3306’ 的 环境 变量 (env 关键 字 ) ， 并 且 在 
8080 端 口 (containerPort) 上 启动 容器 进程 。Pod 的 IP 加 上 这 里 的 容器 
端口 (containerPort) ， 就 组 成 了 一 个 新 的 概念 Endpoint， 它 代表 
着 此 Pod 里 的 一 个 服务 进程 的 对 外 通信 地 址 。 一 个 Pod 也 存在 着 具有 多 
个 Endpoint 的 情况 ， 比 如 当 我 们 把 Tomcat 定 义 为 一 个 Pod 的 时 候 ， 可 以 
对 外 其 露 管理 端口 与 服务 端口 这 两 个 Endpoint ° 


我 们 所 熟悉 的 Docker Volume 在 Kubernetes 里 也 有 对 应 的 概念 
Pod Volume， 后 者 有 一 些 扩展 ， 比 如 可 以 用 分 布 式 文件 系统 GlusterFS 
实现 后 端 存储 功能 ，Pod Volume 是 定义 在 Pod 之 上 ， 然 后 个 各 个 容器 挂 
载 到 自己 的 文件 系统 中 的 。 


这 里 顺便 提 一 下 Kubemetes 的 Event 概 念 ，Event 是 一 个 事件 的 记 
录 ， 记 录 了 事件 的 最 早产 生 时 间 、 最 后 重 现时 间 、 重 复 次 数 、 发 起 


者 、 类 型 ， 以 及 导致 此 事件 的 原因 等 众多 信息 。Event 通 常会 天 联 到 某 
个 具体 的 资源 对 象 上 ， 是 排查 故障 的 重要 参考 信息 ， 之 前 我 们 看 到 
Node 的 描述 信息 包括 了 Event， 而 Pod 同 样 有 Event 记 录 ， 当 我 们 发 现 某 
个 Pod 迟 迟 无 法 创建 时 ， 可 以 用 kubectl describe pod xxxx 来 查看 它 的 描 
述 信息 ， 用 来 定位 问题 的 原因 ， 比 如 下 面 这 个 Event 记 录 信 息 表 明 Pod 
里 的 一 个 容 需 被 探 针 检 测 为 失败 一 次 : 


Events: 
FirstSeen LastSeen Count From 
SubobjectPath Type Reason Message 
10h 12m 32 {kubelet 
k8s-node-1} spec.containers{kube2sky} Warning 
Unhealthy Liveness probe failed: Get 


http://172.17.1.2:8080/healthz: net/http: request canceled 


(Client.Timeout exceeded while awaiting headers) 


每 个 Pod 都 可 以 对 其 能 使 用 的 服务 右上 的 计算 资源 设置 限额 ， 当 
前 可 以 设置 限额 的 计算 资源 有 CPU 与 Memory 两 种 ， 其 中 CPU 的 资源 单 
位 为 CPU (Core) 的 数量 ， 是 一 个 绝对 值 而 非 相 对 值 。 


一 个 CPU 的 配额 对 于 绝 大 多 数 容 圳 来 说 是 相当 大 的 一 个 资源 配额 
了 ， 所 以 ， 在 Kubernetes 里 ， 通 党 以 千 分 之 一 的 CPU 配额 为 最 小 单位 ， 
用 m 来 表示 。 通 常 一 个 容器 的 CPU 配 额 被 定义 为 100 一 300m， 即 占用 
0.1 一 0.3 个 CPU。 由 于 CPU 配额 是 一 个 绝对 值 ， 所 以 无 论 在 拥有 一 个 
Core 的 机 器 上 ， 还 是 在 拥有 48 个 Core 的 机 器 上 ，100m 这 个 配额 所 代表 


的 CPU 的 使 用 量 都 是 一 样 的 。 与 CPU 配额 类 似 ，Memory 配 额 也 是 一 个 
绝对 值 ， 它 的 单位 是 内 存 字 市 数 。 


在 Kubernetes 里 ， 一 个 计算 资源 进行 配额 限定 需要 设 定 以 下 两 个 
参数 。 


e Requests: 该 资源 的 最 小 申请 量 ， 系 统 必 须 满足 要 求 。 
。Limits: 该 资源 最 大 允许 使 用 的 量 ， 不 能 被 突破 ， 当 容器 试图 使 
用 超过 这 个 量 的 资源 时 ， 可 能 会 被 Kubernetes Kill 并 重启 。 


人 


通常 我 们 会 把 Request 设 置 为 一 个 比较 小 的 数值 ， 符 合 容 需 平时 的 
工作 负载 情况 下 的 资源 需求 ， 而 把 Limit 设 置 为 峰值 负载 情况 下 资源 占 
用 的 最 大 量 。 比 如 下 面 这 段 定 义 ， 表 明 MySQL 容 器 申请 最 少 0.25 个 
CPU 及 64MiB 内 存 ， 在 运行 过 程 中 MySQL 容 器 所 能 使 用 的 资源 配额 为 
0.5 个 CPU 及 128MiB 内 存 : 


spec: 
containers: 
- name: db 
image: mysql 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 


cpu: "500m" 


本 市 最 后 ， 笔 者 给 出 Pod 及 Pod 周 边 对 象 的 示意 图 作为 总 结 ， 如 图 
1.8 所 示 ， 后 面部 分 还 会 涉及 这 张 图 里 的 对 象 和 概念 ， 以 进一步 加 强 理 
解 。 


Kubernetes Pod 1 


Endpoint 
(Pod IP+Container port) 


Volume 


container 1 


container 2 


18 ”Pod 及 周边 对 象 


1.4.4 Label (标签 ) 


Label 是 Kubernetes 系 统 中 另外 一 个 核心 概念 。 一 个 Label 是 一 个 
key=value 的 键 值 对 ， 其 中 key 与 Value 由 用 户 自己 指定 。Label 可 以 附加 
到 各 种 资源 对 象 上 ， 例 如 Node、Pod、Service、RC 等 ， 一 个 资源 对 象 
可 以 定义 任意 数量 的 Label， 同 一 个 Label 也 可 以 被 添加 到 任意 数量 的 
资源 对 象 上 去 ，Label 通 常 在 资源 对 象 定义 时 确定 ， 也 可 以 在 对 象 创建 
后 动态 添加 或 者 删除 。 


我 们 可 以 通过 给 指定 的 资源 对 象 捆绑 一 个 或 多 个 不 同 的 Label 来 实 
现 多 维度 的 资源 分 组 管理 功能 ， 以 便于 灵活、 方便 地 进行 资源 分 配 、 
调度 、 配 置 、 部 署 等 管理 工作 。 例 如 : 部 署 不 同 版 本 的 应 用 到 不 同 的 
环境 中 ; 或 者 监控 和 分 析 应 用 (日 志 记 录 、 监 控 、 告 警 ) 等。 一些 常 
用 的 Label 示 例如 下 。 


。 版 本 标签 : “release”: “stable”, “release”: “canary”... 
° Y^ 境 标 


cc 33 


Fy . 。 : 
4: “environment”: “dev”, “environment”: “ga”, “environment” 


: "production" 
° 名 构 标 
Ax: "tier": “frontend”, “tier”: “backend”, “tier”: “middleware” 
。 分 区 标签 : "partition": “customerA”, “partition”: “customerB”... 


。 质量 管控 标签 : “track”: “daily”, “track”: “weekly” 


Label #8 3 TIRE INE”, ZASET PUT ERE MT Label, 
瓯 相当 于 给 它 打 了 一 个 标签 ， 随 后 可 以 通过 Label Selector 选择 
ax) 查询 和 筛选 拥有 某 些 Label 的 资源 对 象 ，Kubernetes 通 过 这 种 方式 
实现 了 类 似 SQL 的 简单 又 通用 的 对 象 查 询 机 制 。 


Label Selector 可 以 被 类 比 为 SQL 语句 中 的 where 碍 询 条 件 ， 例 如 ， 
name=redis-slave 这 个 Label Selector 作 用 于 Pod 时 ， 可 以 被 类 比 为 
select*from pod where pod's name-'redis-slave' 这样 的 语句 。 当 前 有 ji 
FH Label Selector 的 表达 式 : 基于 等 式 的 《Equality-based) 和 基于 集 
HJ (Set-based) ， 前 者 采用 “等 式 类 ”的 表达 式 匹 配 标签 ， 下 面 是 一 些 
具体 的 例子 。 


e name=redis-slave: 匹配 所 有 具有 标签 name=redis-slave 的 资源 对 
象 o 

e env! -production: 匹配 所 有 不 具有 标签 env=production 的 资源 对 
象 ， 比 如 env=test 束 是 满足 此 条 件 的 标签 之 一 。 


而 后 者 则 使 用 集合 操作 的 表达 式 匹 配 标签 ， 下 面 是 一 些 具 体 的 例 


e name in (redis-master ， redis-slave) : 匹配 所 有 具有 标签 
name=redis-master 或 者 name=redis-slave 的 资源 对 象 。 

。name notin (php-frontend) : 匹配 所 有 不 具有 标签 name=php- 
frontend 的 资源 对 象 。 


可 以 通过 多 个 Label Selector 表 达 式 的 组 合 实现 复杂 的 条 件 选 择 ， 
多 个 表达 式 之 间 用 *，” 进 行 分隔 即 可 ， 几 个 条 件 之 间 是 “AND” 的 天 
系 ， 即 同时 满足 多 个 条 件 ， 比 如 下 面 的 例子 : 


name=redis-slave, env!=production 


name notin (php-frontend),env!-production 


Label Selector 在 Kubernetes 中 的 重要 使 用 场景 有 以 下 几 处 。 


。 kube-controllerj 井 程 通过 资源 对 象 RC 上 定义 的 Label Selector iii wt 

要 监控 的 Pod 副 本 的 数量 ， 从 而 实现 Pod 副 本 的 数量 始终 符合 预期 

KENEH tE liE o 

kube-proxy 进 程 通过 Service 的 Label Selector $X M BjPod, A 

动 建立 起 每 个 Service 到 对 应 Pod 的 请 求 转发 路 由 表 ， 从 而 实现 

Service 的 智能 负载 均衡 机 制 。 

。 通 过 对 某 些 Node 定 义 特 定 的 Label， 并 且 在 Pod 定 义 文件 中 使 用 
NodeSelector 这 种 标签 调度 策略 ，kube-scheduler 进 程 可 以 实现 
Pod“ 定 回调 度 ” 的 特性 


在 前 面 的 留言 板 例子 中 ， 我 们 只 使 用 了 一 个 name=XXX 的 Label 
Selector。 让 我 们 看 一 个 更 复杂 的 例子 。 假 设 为 Pod 定 义 了 3 个 Label: 
release、env 和 role， 不 同 的 Pod 定 义 了 不 同 的 Label 值 ， 如 图 1.9 所 示 ， 
如 果 我 们 设置 了 “role=frontend” 的 LabelSelector， 则 会 选取 到 Node 1 和 
Node2 上 的 Pod。 


而 设置 “release=beta” 的 LabelSelector， 则 会 选取 到 Node 2 和 Node3 
上 的 Pod， 如 图 1.10 所 示 。 


j Selector: 
role=frontend 


E23 ----—----EDSDHIS: d 
release: beta 
env: testing 
role: frontend 


Labels: 

release: alpha 

env: development 

role: frontend 
Node 2 


Node 1 


Labels: 
release: beta 
env: production 
role: backend 


Node 3 


K|1.9 Label Selector 的 作用 范围 1 


E 
Labels: p Labels: i; 
release: alpha Jd release: beta i 
env: development y env: testing = 
role: frontend y role: frontend — / 
Node 1 / Node2 / 
Ei Selector: 
release-beta 


release: beta 
env: production 
role: backend 


Node 3 


1.10 Label Selector 的 作用 范围 2 


总 结 : 使 用 Label 可 以 给 对 象 创 建 多 组 标签 ，Label 和 LabelSelector 
共同 构成 了 Kubernetes 系 统 中 最 核心 的 应 用 模型 ， 使 得 被 管理 对 象 能 
够 被 精细 地 分 组 管理 ， 同 时 实现 了 整个 集群 的 高 可 用 性 。 


1.4.5 Replication Controller (RC) 


之 前 已 经 对 Replication Controller (以 后 简称 RC) 的 定义 和 作用 做 
了 一 些 说 明 ， 本 节 对 RC 的 概念 进行 深入 描述 。 


RC 是 Kubernetes 系 统 中 的 核心 概念 之 一 ， 人 简单 来 说 ， 它 其 实 是 
义 了 一 个 期 望 的 场景 ， 即 声明 某 种 Pod 的 副本 数量 在 任意 时 刻 都 符 个 
某 个 预期 值 ， 所 以 RC 的 定义 包括 如 下 几 个 部 分 。 


。 Pod 期 竺 的 副本 数 (replicas) 

。 HT iiis H ESPodBLabel Selector ° 

。 当 Pod 的 副本 数量 小 于 预期 数量 的 时 候 ， 用 于 创建 新 Pod 的 Pod 模 
板 (template) 


下 面 是 一 个 完整 的 RC 定义 的 例子 ， 即 确保 拥有 tier=frontend 标 签 
的 这 个 Pod (运行 Tomcat 容 器 ) 在 整个 Kubernetes 集 群 中 始终 只 有 一 个 
副本 。 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
spec: 
replicas: 1 


selector: 


tier: frontend 
template: 
metadata: 

labels: 
app: app-demo 
tier: frontend 

spec: 

containers: 

- name: tomcat-demo 
image: tomcat 
imagePullPolicy: IfNotPresent 
env: 

- name: GET_HOSTS_FROM 
value: dns 
ports: 


- containerPort: 80 
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的 目标 Pod， 并 确保 目标 Pod 实 例 的 数量 刚好 等 于 此 RC 的 期 望 值 ， 如 果 
有 过 多 的 Pod 副 本 在 运行 ， 系 统 就 会 停 掉 一 些 Pod， 人 否则 系统 残 会 再 自 
动 创建 一 些 Pod。 可 以 说 ， 通 过 RC，Kubernetes 实 现 了 用 户 应 用 集群 的 
高 可 用 性 ， 并 且 大 大 减少 了 系统 管理 员 在 传统 IT 环境 中 需要 完成 的 许 
多 手工 运 维 工作 (如 主机 监控 脚本 、 应 用 监控 脚本 、 故 障 恢复 脚本 


等 ) 。 
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RC 来 实现 Pod 副 本 数量 自动 控制 的 机 制 。 假 如 我 们 的 RC 里 定义 redis- 
slave 这 个 Pod 需 要 保持 3 个 副本 ， 系 统 将 可 能 在 其 中 的 两 个 Node 上 创建 
Pod ° 图 1.11 描 述 了 在 两 个 Node 上 创建 redis-slave Pod 的 情形 。 


Master 
Replication Controller 
pae N 
x \ 
Y Y 
Pod 1 Pod2 
Node 1 Node 2 Node 3 


图 1.11 在 两 个 Node 上 创建 redis-slave Pod 


假设 Node 2 上 的 Pod 2 意外 终止 ,根据 RC 定 义 的 replicas 数 量 2， 
Kubernetes 将 会 目 动 创建 并 启动 一 个 新 的 Pod， 以 保证 整个 集群 中 始终 
有 了 两 个 redis-slave Pod 在 运行 。 


如 图 1.12 所 示 ， 系 统 可 能 选择 Node 3 或 者 Node 1 来 创建 一 个 新 的 
Pod ° 


Pod 1 Pod 2 


Node 1 


Node 2 


Pod 1 Pod 3 
Node 1 Node 2 Node 3 
或 
Pod 1 Pod 3 
Node 1 Node 2 Node 3 


图 1.12 根据 RC 定义 创建 新 的 Pod 


此 外 ， 在 运行 时 ， 我 们 可 以 通过 修改 RC 的 副本 数量 ， 来 实现 Pod 
的 动态 缩放 (Scaling) 功能 ， 这 可 以 通过 执行 kubectl scale 命 令 来 一 键 
完成 : 


$ kubectl scale rc redis-slave --replicas=3 


scaled 


Scaling 的 执行 结果 如 图 1.13 所 示 。 


Pod 1 


Node 1 


Pod 2 


Node 2 


Node 3 


| 


Pod 1 Pod 2 Pod 3 
Node 1 Node 2 Node 3 
或 
redis- redis- 
slave slave 
Pod1 Pod 3 Pod 2 
Node 1 Node 2 Node 3 


图 1.13 ”Scaling 的 执行 结果 


需要 注意 的 是 ， 删 除 RC 并 不 会 影响 通过 该 RC 已 创建 好 的 Pod。 为 
了 删除 所 有 Pod， 可 以 设置 replicas 的 值 为 0， 然 后 更 新 该 RC。 另 外 ， 
kubectl 提 供 了 stop 和 delete 命 令 来 一 次 性 删除 RC 和 RC 控制 的 全 部 Pod。 


当 我 们 的 应 用 升级 时 ， 通 常会 通过 Build 一 个 新 的 Docker 镜 像 ， 并 
用 新 的 镜像 版 本 来 蔡 代 旧 的 版 本 的 方式 达到 目的 。 在 系统 升级 的 过 程 
中 ， 我 们 希望 是 平滑 的 方式 ， 比 如 当前 系统 中 10 个 对 应 的 旧版 本 的 
Pod， 最 佳 的 方式 是 旧版 本 的 Pod 每 次 停止 一 个 ， 同 时 创建 一 个 新 版 本 
的 Pod， 在 整个 升级 过 程 中 ， 此 消 彼 长 ， 而 运行 中 的 Pod 数 量 始 终 是 10 
个 ， 几 分 钟 以 后 ， 当 所 有 的 Pod 都 已 经 是 新 版 本 的 时 候 ， 升 级 过 程 完 


成 。 通 过 RC 的 机 制 ， ey 
性 ， 被 称 为 “滚动 升级 ”(Rolling Update) ， 具 体 的 操作 方法 详 见 第 
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Controller 同 名 ， 同 时 这 个 词 也 无 法 准确 表达 它 的 本 意 ， 所 以 在 
Kubernetes 1.2 的 时 候 ， 它 就 升级 成 了 男 外 一 个 新 的 概念 Replica 
Set， 官 方 解 释 为 “下 一 代 的 RC”， 它 与 RC 当前 存在 的 唯一 区 别 是 
Replica Sets 支 持 基于 集合 的 Label selector (Set-based selector) ， 而 RC 
只 支持 基于 等 式 的 Label Selector (equality-based selector) ， 这 使 得 
Replica Set 的 功能 更 强 ， 下 面 是 等 价 于 之 前 RC 例子 的 Replica Set 的 定义 

(省 去 了 Pod 模 板 部 分 的 内 容 ) : 


apiVersion: extensions/vibetai 
kind: ReplicaSet 
metadata: 
name: frontend 
spec: 
selector: 
matchLabels: 
tier: frontend 
matchExpressions: 
- (key: tier, operator: In, values: [frontend] } 


template: 


kubectl 命 令 行 工具 适用 于 RC 的 绝 大 部 分 命令 都 同样 适用 于 Replica 
Set。 此 外 ， 当 前 我 们 很 少 单独 使 用 Replica Set， 它 主要 被 Deployment 
这 个 更 高 层 的 资源 对 象 所 使 用 ， 从 而 形成 一 整套 Pod 创 建 、 删 除 、 更 
源 的 编排 机 制 。 当 我 们 使 用 Deployment 时 ， 无 须 关 心 它 是 如 何 创建 和 
维护 Replica Set 的 ， 这 一 切 都 是 目 动 发 生 的 。 


Replica Set 与 Deployment 这 两 个 重要 资源 对 象 逐 步 殖 换 了 之 前 的 
RC 的 作用 ， 是 Kubernetes 1.3 里 Pod 上 自动 扩容 (伸缩 ) 这 个 告警 功能 实 
现 的 基础 ， 也 将 继续 在 Kubernetes 未 来 的 版 本 中 发 挥 重 要 的 作用 。 


最 后 我 们 总 结 一 下 关于 RC (Replica Set) 的 一 些 特性 与 作用 。 


在 大 多 数 情况 下 ， 我 们 通过 定义 一 个 RC 实现 Pod 的 创建 过 程 及 副 
本 数量 的 目 动 控制 。 

RC 里 包括 完整 的 Pod 定 义 模 板 。 

RC 通过 Label Selector 机 制 实现 对 Pod 副 本 的 自动 控制 。 

过 改变 RC 里 的 Pod 副 本 数量 ， 可 以 实现 Pod 的 扩容 或 缩 容 功 能 。 
过 改变 RC 里 Pod 模 板 中 的 镜像 版 本 ， 可 以 实现 Pod 的 滚动 升级 功 
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1.4.6 Deployment 


DeploymentzéKubernetes 1.2 引 入 的 新 概念 ， 引 入 的 目的 是 为 了 更 好 地 解决 Pod 的 编排 
问题 。 为 此 ，Deployment 在 内 部 使 用 了 Replica Set 来 实现 目的 ， 无 论 从 Deployment 的 作用 
与 目的 、 它 的 YAM 定 义 ， 还 是 从 它 的 具体 命令 行 操作 来 看 ， 我 们 都 可 以 把 它 看 作 RC 的 一 
次 升级 ， 两 者 的 相似 度 超过 90%。 


Deployment 相 对 于 RC 的 一 个 最 大 升级 是 我 们 可 以 随时 知道 当前 Pod“ 部 署 * 的 进度 。 实 
际 上 由 于 一 个 Pod 的 创建 、 调 度 、 绑 定 节 点 及 在 目标 Node 上 启动 对 应 的 容器 这 一 完整 过 程 
需要 一 定 的 时 间 ， 所 以 我 们 期 竺 系统 启动 N 个 Pod 副 本 的 目标 状态 ， 实 际 上 是 一 个 连续 变 
化 的 “部 署 过 程 ”导致 的 最 终 状态 。 


Deployment 的 典型 使 用 场景 有 以 下 几 个 。 


。 创建 一 个 Deployment 对 象 来 生成 对 应 的 Replica Set 并 完成 Pod 副 本 的 创建 过 程 。 

。 检查 Deployment 的 状态 来 看 部 署 动作 是 否 完成 《Pod 副 本 的 数量 是 否 达 到 预期 的 
值 ) 

。 更 新 Deployment 以 创建 新 的 Pod (比如 镜像 升级 ) 

。 如 有 果 当 前 Deployment 不 稳定 ， 则 回 深 到 一 个 早先 的 Deployment 版 本 。 

。 挂 起 或 者 恢复 一 个 Deployment ° 


Deployment 的 定义 与 Replica Set 的 定义 很 类 似 ， 除 了 API 声 明 与 Kind 类 型 等 有 所 区 


别 : 
apiVersion: extensions/vibetal apiVersion: v1 
kind: Deployment kind: ReplicaSet 
metadata: metadata: 
name: nginx-deployment name: nginx-repset 


下 面 我 们 通过 运行 一 些 例子 来 一 起 直观 地 感受 这 个 新 概念 。 首 先 创 建 一 个 名 为 
tomcat-deployment.yaml 的 Deployment 描 述 文 件 ， 内 容 如 下 : 


apiVersion: extensions/vibetal 


kind: Deployment 


metadata: 


name: frontend 


spec: 


replicas: 1 
selector: 
matchLabels: 
tier: frontend 


matchExpressions: 


- {key: tier, operator: In, values: 


template: 
metadata: 

labels: 
app: app-demo 
tier: frontend 

spec: 

containers: 

- name: tomcat-demo 
image: tomcat 
imagePullPolicy: IfNotPresent 
ports: 


- containerPort: 8080 


[frontend] } 


ze 


yii 4 8 Deployment: 


# kubectl create -f tomcat-deployment.yaml 


deployment "tomcat-deploy" created 


述 命令 查看 Deployment 的 信息 : 


# kubectl get deployments 


NAME DESIRED CURRENT UP-TO-DATE 


tomcat - deploy 1 1 


1 


AVAILABLE 


AGE 


4m 


对 上 述 输出 中 涉及 的 数量 解释 如 下 。 


。 DESIRED: Pod 副 本 数量 的 期 望 值 ， 即 Deployment 里 定义 的 Replica ° 

。CURRENT: 当前 Replica 的 值 ， 实 际 上 是 Deployment 所 创建 的 Replica Set 里 的 Replica 
值 ， 这 个 值 不 断 增加 ， 直 到 达到 DESIRED 为 止 ， 表明 整个 部 署 过 程 完 成 。 

e UP-TO-DATE: 最 新 版 本 的 Pod 的 副本 数量 ， 用 于 指示 在 滚动 升级 的 过 程 中 ， 有 多 少 
个 Pod 副 本 已 经 成 功 升级 。 

e AVAILABLE: 当前 集群 中 可 用 的 Pod 唱 


Ta 


= 


数量 ， 即 集群 中 当前 存活 的 Pod 数 量 。 


运行 下 壕 命令 查看 对 应 的 Replica Set， 我 们 看 到 它 的 命名 跟 Deployment 的 名 字 有 关 
系 : 


#kubectl get rs 
NAME DESIRED CURRENT AGE 
tomcat -deploy-1640611518 1 1 1m 


运行 下 述 命 令 查看 创建 的 Pod， 我 们 发 现 Pod 的 命名 以 Deployment 对 应 的 Replica Seth’) 
名 字 为 前 缀 ， 这 种 命名 很 清晰 地 表明 了 一 个 Replica Set 创 建 了 哪些 Pod， 对 于 Pod 滚 动 升级 
这 种 复杂 的 过 程 来 说 ， 很 容易 排查 错误 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


tomcat -deploy-1640611518-zhrsc 1/1 Running (0) 3m 


^ 


扩展 


describe deployments， 可 以 清楚 地 看 到 Deployment 控 制 的 Pod 的 水 习 
过 程 ， 此 命令 的 输出 比较 多 ， 这 里 不 再 性 述 。 


1.4.7 Horizontal Pod Autoscaler (HPA) 


在 前 两 节 提 到 过 ， 通 过 手工 执行 kubectl scale 命 令 ， 我 们 可 以 实现 
Pod 扩 容 或 缩 容 。 如 果 仅 仅 到 此 为 止 ， 显 然 不 符合 谷歌 对 Kubernetes 的 
定位 目标 自动 化 、 智 能 化 。 在 谷歌 看 来 ， 分 布 式 系统 要 能 够 根据 
当前 负载 的 变化 情况 目 动 触 发 水 平 扩展 或 缩 容 的 行为 ， 因 为 这 一 过 程 
可 能 是 频繁 发 生 的 、 不 可 预料 的 ， 所 以 手动 控制 的 方式 是 不 现实 的 。 


因此 ，Kubernetes 的 1.0 版 本 实现 后 ， 这 帮 大 牛 们 或 已 经 在 默默 研 

究 Pod 智 能 扩容 的 特性 了 ， 并 在 Kubernetes1.1 的 版 本 中 首次 发 布 这 一 重 

量 级 新 特性 一 -Horizontal Pod Autoscaling。 随 后 的 1.2 版 本 中 HPA 被 升 

级 为 稳定 版 本 (apiVersion: autoscaling/v1) ， 但 同时 仍然 保留 旧版 本 

(apiVersion: extensions/vlbetal) ， 官 方 的 计划 是 在 1.3 版 本 里 先 移 除 
旧版 本 ， 并 且 会 在 1.4 版 本 里 彻底 移 除 旧版 本 的 文 持 。 


Horizontal Pod Autoscaling 人 简称 HPA， 意 思 是 Pod 横 癌 目 动 扩容 ， 
与 之 表 的 RC、Deployment 一 样 ， 也 属于 一 种 Kubernetes 资 源 对 象 。 通 
过 追踪 分 析 RC 控 制 的 所 有 目标 Pod 的 负载 变化 情况 ， 来 确定 是 否 需 要 
针对 性 地 调整 目标 Pod 的 副本 数 ， 这 是 HPA 的 实现 原理 。 当 前 ，HPA 可 
以 有 以 下 两 种 方式 作为 Pod 负 载 的 度量 指标 。 


e CPUUtilizationPercentage ° 
。 应 用 程序 自 定义 的 度量 指标 ， 比 如 服务 在 每 秒 内 的 相应 的 请 求 数 
(TPS 或 QPS) 。 


CPUUtilizationPercentage 是 一 个 算术 平均 值 ， 即 目标 Pod 所 有 副本 
自身 的 CPU 利用 率 的 平均 值 。 一 个 Pod 自 身 的 CPU 利用 率 是 该 Pod 当 前 
CPU 的 使 用 量 除 以 它 的 Pod Request 的 值 ， 比 如 我 们 定义 一 个 Pod 的 Pod 
Request 为 0.4， 而 当前 Pod 的 CPU 使 用 量 为 0.2， 则 它 的 CPU 使 用 率 为 
50%， 如 此 一 来 ， 我 们 就 可 以 就 泪 出 来 一 个 RC 控制 的 所 有 Pod 副 本 的 
CPU 利用 率 的 算术 平均 值 了 。 如 果 某 一 时 刻 CPUUtilizationPercentage 
的 值 超过 80%， 则 意味 着 当前 的 Pod 副 本 数 很 可 能 不 足以 支撑 接 下 来 更 
多 的 请 求 ， 需 要 进行 动态 扩容 ， 而 当 请 求 高 峰 时 段 过 去 后 ，Pod 的 CPU 
利用 率 又 会 降下 来 ， 此 时 对 应 的 Pod 副 本 数 应 该 自动 减少 到 一 个 合理 
的 水 平 。 


CPUUtilizationPercentage 计 算 过 程 中 使 用 到 的 Pod 的 CPU 使 用 量 通 
常 是 1 分 钟 内 的 平均 值 ， 目 前 通过 查询 Heapster 扩 展 组 件 来 得 到 这 个 
值 ， 所 以 需要 安装 部 署 Heapster， 这 样 一 来 便 增 加 了 系统 的 复杂 度 和 
实施 HPA 特 性 的 复杂 度 ， 因 此 ， 未 来 的 计划 是 Kubernetes 目 身 实现 一 个 
基础 性 能 数据 采集 模块 ， 从 而 更 好 地 支持 HPA 和 其 他 需要 用 到 基础 性 
能 数据 的 功能 模块 。 此 外 ， 我 们 也 看 到 ， 如 果 目 标 Pod 没 有 定义 Pod 
Request 的 值 ， 则 无 法 使 用 CPUUtilizationPercentage 来 实现 Pod 横 癌 上 自动 
扩容 的 能 力 。 除 了 使 用 CPUUtilizationPercentage，Kubernetes 从 1.2 版 本 
开始 ， 淮 试 文 持 应 用 程序 自 定 义 的 度量 指标 ， 目 前 仍然 为 实 难 特性， 
不 建议 在 生产 环境 中 使 用 。 


下 面 是 HPA 定 义 的 一 个 具体 例子 : 


apiVersion: autoscaling/vi 
kind: HorizontalPodAutoscaler 


metadata: 


name: php-apache 
namespace: default 
spec: 

maxReplicas: 10 

minReplicas: 1 

scaleTargetRef: 
kind: Deployment 
name: php-apache 


targetCPUUtilizationPercentage: 90 


根据 上 面 的 定义 ， 我 们 可 以 知道 这 个 HPA 控 制 的 目标 对 象 为 一 个 
名 叫 php-apache 的 Deployment 里 的 Pod 副 本 ， 当 这 些 Pod 副 本 的 
CPUUtilizationPercentage 的 值 超过 90% 时 会 触发 自动 动态 扩容 行为 ， 扩 
容 或 缩 容 时 必须 满足 的 一 个 约束 条 件 是 Pod 的 副本 数 要 介 于 1 与 10 之 
lA] o 


除了 可 以 通过 直接 定义 yaml 文 件 并 且 调 用 kubectrl create 的 命令 来 
创建 一 个 HPA 资 源 对 象 的 方式 ， 我 们 还 能 通过 下 面 的 简单 命令 行 直 接 
创建 等 价 的 HPA 对 和 象 : 


# kubectl autoscale deployment php-apache --cpu- 


percent=90 --min=1 --max=10 


第 2 章 将 会 给 出 一 个 完整 的 HPA 例 子 来 说 明 其 用 法 和 功能 。 


1.4.8 Service (服务 ) 


1. 概 壕 


Service 也 是 Kubernetes 里 的 最 核心 的 资源 对 象 之 一 ，Kubernetes 里 
的 每 个 Service 其 实 就 是 我 们 经 常 提起 的 微服 务 架 构 中 的 一 个 “微服 
务 ”， 之 前 我 们 所 说 的 Pod、RC 等 资源 对 象 其 实 都 是 为 这 市 所 说 的 “ 服 
25 "— Kubernetes Service fill * A X” HI » Él 1.14 zs T Pod ^ RC 5 
Service 的 逻辑 关系 。 
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图 1.14 Pod、RC 与 Service 的 关系 


从 图 1.14 中 我 们 看 到 ，Kubernetes 的 Service 定 义 了 一 个 服务 的 访问 
入 口 地 址 ， 前 端的 应 用 (Pod) 通过 这 个 入 口 地 址 访问 其 背后 的 一 组 
由 Pod 副 本 组 成 的 集群 实例 ，Service 与 其 后 端 Pod 副 本 集群 之 间 则 是 通 
i Label Selector 来 实现 “无 颖 对 接 ” 的 。 而 RC 的 作用 实际 上 是 保证 
Service 的 服务 能 力 和 服务 质量 始终 处 于 预期 的 标准 。 


通过 分 析 、 识 别 并 建 模 系统 中 的 所 有 服务 为 微服 务 
Kubernetes Service， 最 终 我 们 的 系统 由 多 个 提供 不 同业 务 能 力 而 又 彼 
此 独立 的 微服 务 单元 所 组 成 ， 服 务 之 间 通 过 TCP/IP 进 行 通 信 ， 从 而 形 
成 了 我 们 强大 而 又 灵活 的 弹性 网 格 ， 拥 有 了 强大 的 分 布 式 能 力 、 弹 性 
扩展 能 力 、 容 错 能 力 ， 与 此 同时 ， 我 们 的 程序 架构 也 变 得 简单 和 直观 
许多 ， 如 图 1.15 所 示 。 


既然 每 个 Pod 都 会 被 分 配 一 个 单独 的 IP 地 址 ， 而 且 每 个 Pod 都 提供 
了 一 个 独立 的 Endpoint (Pod IP+ContainerPort) 以 被 客户 端 访问 ， 现 
在 多 个 Pod 副 本 组 成 了 一 个 集群 来 提供 服务 ， 那 么 客户 端 如 何 来 访问 
它们 呢 ? 一 般 的 做 法 是 部 署 一 个 负载 均衡 器 (软件 或 硬件 ) ， 为 这 组 
Pod 开 启 一 个 对 外 的 服务 端口 如 8000 端 口 ， 并 且 将 这 些 Pod 的 Endpoint 
列表 加 入 8000 端 口 的 转发 列表 中 ， 客 户 端 束 可 以 通过 负载 均衡 如 的 对 
外 IP 地 址 + 服务 端口 来 访问 此 服务 ， 而 客户 端的 请 求 最 后 会 被 转发 到 哪 
个 Pod， 则 由 负载 均衡 絮 的 算法 所 决定 。 
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图 1.15 Kubernetes 所 提供 的 微服 务 网 格 以 构 
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请 求 转发 到 后 端的 某 个 Pod 实 例 上 ， 并 在 内 部 实现 服务 的 负载 均衡 与 
会 话 你 持 机 制 。 但 Kubemetes 发 明了 一 种 很 巧妙 又 影响 深远 的 设计 : 
Service 不 是 共用 一 个 负载 均衡 器 的 IP 地 址 ， 而 是 每 个 Service 分 配 了 一 
个 全 局 唯一 的 虚拟 IP 地 址 ， 这 个 虚拟 IP 被 称 为 Cluster IP。 这 样 一 来 ， 
每 个 服务 束 变 成 了 具备 唯一 IP 地 址 的 “通信 节点 ”， 服 务 调用 就 变 成 了 
最 基础 的 TCP 网 络 通信 问题 。 


我 们 知道 ，Pod 的 Endpoint 地 址 会 随 着 Pod 的 销毁 和 重新 创建 而 发 
生 改 变 ， 因 为 新 Pod 的 IP 地 址 与 之 前 旧 Pod 的 不 同 。 而 Service 一 旦 创 
建 ，Kubernetes 束 会 自动 为 它 分 配 一 个 可 用 的 Cluster IP， 而 且 在 
Service 的 整个 生命 周期 内 ， 它 的 Cluster IP 不 会 发 生 改 变 。 于 是 ， 服 务 
发 现 这 个 环 手 的 问题 在 Kubernetes 的 架构 里 也 得 以 轻松 解决 : 只 要 用 
Service 的 Name 与 Service 的 Cluster IP 地 址 做 一 个 DNS 域 名 映射 即 可 完美 
解决 问题 。 现 在 想 想 ， 这 真是 一 个 很 棒 的 设计 。 


说 了 这 么 久 ， 下 面 我 们 动手 创建 一 个 Service， 来 加 深 对 它 的 理 
解 。 首 先 我 们 创建 一 个 名 为 tomcat-service.yaml 的 定义 文件 ， 内 容 如 
下 : 


apiVersion: vi 
kind: Service 
metadata: 
name: tomcat-service 
spec: 


ports: 


- port: 8080 
selector: 


tier: frontend 


上 述 内 容 定义 了 一 个 名 为 "tomcat-service” 的 Service， 它 的 服务 端 
口 为 8080， 拥 有 “tier=frontend” 这 个 Label 的 所 有 Pod 实 例 都 属于 它 ， 运 
行 下 面 的 命令 进行 创建 : 


#kubectl create -f tomcat-server.yaml 


service "tomcat-service" created 


注意 到 我 们 之 前 在 tomcat-deployment.yaml 里 定义 的 Tomcat 的 Pod 
刚好 拥有 这 个 标签 ， 所 以 我 们 刚才 创建 的 tomcat-service 已 经 对 应 到 了 
一 个 Pod 实 例 ， 运 行 下 面 的 命令 可 以 查看 tomcat-service 的 Endpoint 列 
表 ， 其 中 172.17.1.3 是 Pod 的 IP 地 址 ， 端 口 8080 是 Container 骏 露 的 端 
O: 


# kubectl get endpoints 


NAME ENDPOINTS AGE 
kubernetes 192.168.18.131:6443 15d 
tomcat-service 172.17.1.3:8080 im 


UR BY BEA SEI]: “说 好 的 Service 的 Cluster IPI? 怎么 没有 看 
Bll? ”我 们 运行 下 面 的 命令 即 可 看 到 tomct-service 被 分 配 的 Cluster IP 
更 多 的 信息 : 


# kubectl get svc tomcat-service -o yaml 
apiVersion: v1 
kind: Service 
metadata: 
creationTimestamp: 2016-07-21T17:05:52Z 
name: tomcat-service 
namespace: default 
resourceVersion: "23964" 
selfLink: 
/api/vi/namespaces/default/services/tomcat-service 
uid: 61987d3c-4f65-11e6-a9d8-000c29ed42c1 
spec: 
clusterIP: 169.169.65.227 
ports: 
- port: 8080 
protocol: TCP 
targetPort: 8080 
selector: 
tier: frontend 
sessionAffinity: None 
type: ClusterIP 
status: 


loadBalancer: {} 


在 spec.ports 的 定义 中 ，targetPort 属 性 用 来 确定 提供 该 服务 的 容器 
所 暴露 (EXPOSE) 的 端口 号 ， 即 具体 业务 进程 在 容器 内 的 targetPort 


上 提供 TCP/IP 授 入 ; 而 port 属 性 则 定义 了 Service 的 虚 端 口 。 前 面 我 们 
定义 Tomcat 服 务 的 时 候 ， 没 有 指定 targetPort， 则 默认 targetPort 与 port 相 
la] o 


接 下 来 ， 我 们 来 看 看 Service 的 多 端口 问题 。 


很 多 服务 都 存在 多 个 端口 的 问题 ， 通 常 一 个 端口 提供 业务 服务 ， 
男 外 一 个 端口 提供 管理 服务 ， 比 如 Mycat、Codis 等 常见 中 间 件 。 
Kubernetes Service 文 持 多 个 Endpoint， 在 存在 多 个 Endpoint 的 情况 下 ， 
要 求 每 个 Endpoint 定 义 一 个 名 字 来 区 分 。 下 面 是 Tomcat 多 端口 的 
Service 定 义 样 例 : 


apiVersion: v1 
kind: Service 
metadata: 
name: tomcat-service 
spec: 
ports: 
- port: 8080 
name: service-port 
- port: 8005 
name: shutdown-port 
selector: 


tier: frontend 


多 端口 为 什么 需要 给 每 个 端口 命名 呢 ? 这 就 涉及 Kubernetes 的 服 
务 发 现 机 制 了 ， 我 们 接 下 来 进行 讲解 。 


2.Kubernetes 的 服务 发 现 机 制 


任何 分 布 式 系统 都 会 涉及 “服务 发 现 ” 这 个 基础 问题 ， 大 部 分 分 布 
式 系统 通过 提供 特定 的 API 接 口 来 实现 服务 发 现 的 功能 ， 但 这 样 做 会 
导致 平台 的 侵入 性 比较 强 ， 也 增加 了 开发 测 弃 的 困难 。Kubernetes 则 
采用 了 直观 朴 隶 的 思路 去 解决 这 个 坏 手 的 问题 。 


首先 ， 每 个 Kubernetes 中 的 Service 都 有 一 个 唯一 的 Cluster IP 以 及 


唯一 的 名 字 ， 而 名 字 是 由 开发 者 自己 定义 的 ， 部 署 的 时 候 也 没 必要 改 
变 ， 所 以 完全 可 以 固定 在 配置 中 。 接 下 来 的 问题 就 是 如 何 通 过 Service 
的 名 字 找 到 对 应 的 Cluster IP? 


最 早 的 时 候 Kubernetes 采 用 了 Linux 环 境 变 量 的 方式 解决 这 个 问 
题 ， 即 每 个 Service 生 成 一 些 对 应 的 Linux 环 境 变 量 (ENV) ， 并 在 每 个 
Pod 的 容器 在 启动 时 ， 目 动 注入 这 些 环境 变量 ， 以 以 下 是 tomcat-service 


产生 的 环境 变量 条 目 : 


TOMCAT SERVICE SERVICE H0ST-169.169.41.218 


TOMCAT SERVICE SERVICE PORT SERVICE PORT-8080 


TOMCAT SERVICE SERVICE PORT SHUTDOWN PORT-8005 


TOMCAT SERVICE SERVICE PORT-8080 


TOMCAT SERVICE PORT 8005 TCP PORT-8005 


TOMCAT SERVICE PORT-tcp://169.169.41.218:8080 


TOMCAT SERVICE 
TOMCAT SERVICE 
TOMCAT SERVICE 
TOMCAT SERVICE 
TOMCAT SERVICE 


PORT 


8080 TCP ADDR-169.169.41.218 


PORT 


8080 TCP-tcp://169.169.41.218:8080 


PORT 


PORT 


8080 TCP PROTO-tcp 
8080 TCP PORT-8080 


PORT 


8005 TCP-tcp://169.169.41.218:8005 


TOMCAT SERVICE PORT 8005 TCP ADDR-169.169.41.218 


TOMCAT SERVICE PORT 8005 TCP PROTO-tcp 


上 述 环境 变量 中 ， 比 较 重 要 的 是 前 3 条 环境 变量 ， 我 们 可 以 看 到 ， 
每 个 Service 的 了 地 址 及 端口 都 症 有 标准 的 命名 规范 的 ， 遵 循 这 个 命名 
规范 ， 束 可 以 通过 代码 访问 系统 环境 变量 的 方式 得 到 所 需 的 信息 ， 实 
现 服务 调用 。 


考虑 到 环境 变量 的 方式 获取 Service 的 卫 与 端口 的 方式 仍然 不 太 方 
便 ， 不 够 直观 ， 后 来 Kubernetes 通 过 Add-On 增 值 包 的 方式 引入 了 DNS 
系统 ， 把 服务 名 作为 DNS 域 名 ， 这 样 一 来 ， 程 序 就 可 以 直接 使 用 服务 
名 来 建立 通信 连接 了。 目前 Kubermetes 上 的 大 部 分 应 用 都 已 经 采用 了 
DNS 这 些 新 兴 的 服务 发 现 机 制 ， 后 面 的 章 市 中 我 们 会 讲述 如 何 部 署 这 
套 DNS 系 统 。 


3. 外 部 系统 访问 Service 的 问题 


为 了 更 加 深入 地 理解 和 和 掌握 Kubernetes ， 我 们 需要 弄 明白 
Kubernetes 里 的 “三 种 IP” 这 个 关键 问题 ， 这 三 种 IP 分 别 如 下 。 


e Node IP: Node 闻 点 的 IP 地 址 。 
e Pod IP: Pod 的 IP 地 址 。 
。 Cluster IP: Service 的 IP 地 址 。 


HI, Node 卫 是 Kubemetes 集 群 中 每 个 和 点 的 物理 网 卡 的 了 地 
址 ， 这 是 一 个 真实 存在 的 物理 网 络 ， 所 有 属于 这 个 网 络 的 服务 器 之 间 
都 能 通过 这 个 网 络 直 接 通信 ， 不 管 它们 中 是 否 有 部 分 节点 不 属于 这 个 
Kubernetes 集群 。 这 也 表明 了 Kubernetes 人 集群 之 外 的 和 点 访问 


Kubernetes 集 群 之 内 的 某 个 节点 或 者 TCP/AP 服 务 的 时 候 ， 必 须要 通过 
Node IP 进 行 通 信 » 


其 次 ，Pod IP 是 每 个 Pod 的 IP 地 址 ， 它 是 Docker Engine 根 据 docker0 
网 桥 的 IP 地 址 段 进 行 分 配 的 ， 通 常 古 一 个 虚拟 的 二 层 网 络 ， 前 面 我 们 
说 过 ，Kubernetes 要 求 位 于 不 同 Node 上 的 Pod 能 够 彼此 直接 通信 ， 所 以 
Kubermnetes 里 一 个 Pod 里 的 容 句 访问 男 外 一 个 Pod 里 的 容器 ， 束 是 通过 
Pod IP 所 在 的 虚拟 二 层 网 络 进行 通信 的 ， 而 真实 的 TCP/IP 流 量 则 是 通 
过 Node IP 所 在 的 物理 网 卡 流出 的 。 


最 后 ， 我 们 说 说 Service 的 Cluster IP， 它 也 是 一 个 虚拟 的 PP， 但 更 
像 是 一 个 “伪造 ”的 IP 网 络 ， 原 因 有 以 下 几 点 。 


。 Cluster IP 仅 仅 作 用 于 Kubernetes Service 这 个 对 象 ， 并 由 Kubernetes 
管理 和 分 配 IP 地 址 (来 源 于 Cluster IP 地 址 池 ) 。 

e Cluster IP 无 法 被 Ping， 因 为 没有 一 个 “实体 网 络 对 象 ” 来 响应 。 

。 Cluster IP 只 能 结合 Service Port 组 成 一 个 具体 的 通信 端口 ， 单 独 的 
Cluster IP 不 具备 TCP/IP 通 信 的 基础 ， 并 且 它 们 属于 Kubernetes 集 
群 这 样 一 个 封闭 的 空间 ， 集 群 之 外 的 节点 如 果 要 访问 这 个 通信 端 
口 ， 则 需要 做 一 些 额外 的 工作 。 

。 在 Kubernetes 集 群 之 内 ，Node IPW] ` Pod IP 5j Cluster IP 网 之 间 
的 通信 ， 采 用 的 是 Kubernetes 目 己 设 计 的 一 种 编程 方式 的 特殊 的 
路 由 规则 ， 与 我 们 所 吕 知 的 IP 路 由 有 很 大 的 不 同 。 


根据 上 面 的 分 析 和 总 结 ， 我 们 基本 明日 了 : Service 的 Cluster IP 属 
于 Kubernetes 集 群 内 部 的 地 址 ， 无 法 在 集群 外 部 直接 使 用 这 个 地 址 。 
那么 矛盾 来 了 : 实际 上 我 们 开发 的 业务 系统 中 肯定 多 少 有 一 部 分 服务 
是 要 提供 给 Kubernetes 集 群 外 部 的 应 用 或 者 用 户 来 使 用 的 ， 典 型 的 例 
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访问 它 ? 


采用 NodePort 是 解决 上 述 问 题 的 最 直接 、 最 有 效 、 最 常用 的 做 
法 。 具 体 做 法 如 下 ， 以 tomcat-service 为 例 ， 我 们 在 Service 的 定义 里 做 
如 下 扩展 即 可 (黑体 字 部 分 ) : 


apiVersion: vi 

kind: Service 
metadata: 

name: tomcat-service 
spec: 

type: NodePort 

ports: 

- port: 8080 
nodePort: 31002 

selector: 


tier: frontend 


其 中 ，nodePort: 31002 这 个 属性 表明 我 们 手动 指定 tomcat-service 
的 NodePort 为 31002， 否 则 Kubernetes 会 目 动 分 配 一 个 可 用 的 端口 。 接 
下 来 ， 我 们 在 浏览 器 里 访问 http://<nodePort IP>: 31002/， 就 可 以 看 到 
Tomat 的 欢迎 界面 了 ， 如 图 1.16 所 示 。 


192.168.18.131:31002 
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1.16 通过 NodePort 访 问 Service 


NodePort 的 实现 方式 是 在 Kubernetes 集 群 里 的 每 个 Node 上 为 需要 
外 部 访问 的 Service 开 局 一 个 对 应 的 TCP 监 听 端 口 ， 外 部 系统 只 要 用 任 
意 一 个 Node 的 卫 地 址 + 具体 的 NodePort 山 口号 即 可 访问 此 服务 ， 在 任意 
Node 上 运行 netstat 命 令 ， 我 们 束 可 以 看 到 有 NodePort 端 口 被 监听 


# netstat -tlp|grep 31002 
tcp6 0 © [::]:31002 gee al Eas 
LISTEN 1125/kube- proxy 


但 NodePort 还 没有 完全 解决 外 部 访问 Service 的 所 有 问题 ， 比 如 负 
载 均衡 问题 ， 假 如 我 们 的 集群 中 有 10 个 Node， 则 此 时 最 好 有 一 个 负载 
均衡 句 ， 外 部 的 请 求 只 需 访 问 此 负载 均衡 需 的 了 P 地 址 ， 由 负载 均衡 坑 
负责 转发 流量 到 后 面 某 个 Node 的 NodePort 上 。 如 图 1.17 所 示 。 


客户 端 外 部 网 络 
(RRMA) 
— i 企业 内 部 网 络 
Load balancer 
Kubernetes 集 群 


| 
E NodePort 


1.17 NodePort Load balancer 


1.17 中 的 Load balancer 组 件 独立 于 Kubernetes 集 群 之 外 ， 通 第 是 
一 个 硬件 的 负载 均衡 器 ， 或 者 是 以 软件 方式 实现 的 ， 例 如 HAProxy 或 
者 Nginx。 对 于 每 个 Service , Po) es Ed ee ose 
balancer 实 例 来 转发 流量 到 后 端的 Node 上， 这 的 确 增加 了 工作 量 及 出 
错 的 概率 。 于 是 Kubernetes 提 供 了 目 动 化 的 解决 方案 ， 如 果 我 们 的 集 
群 运行 在 谷歌 的 GCE 公 有 云 上 ， 那 么 只 要 我 们 把 Service 的 
type=NodePort 改 为 type=LoadBalancer， 此 时 Kubernetes 会 自动 创 
个 对 应 的 Load balancer 实 例 并 返回 它 的 IP 地 址 供 外 部 客户 端 使 用 。 
他 公有 云 提供 商 只 要 实现 了 支持 此 特性 的 驱动 ， ae 
的 。 此 外 ， 裸 机 上 的 类 似 机 制 (Bare Metal Service Load Balancers) 也 
正在 被 开发 。 


1.4.9 Volume (FEE) 


Volume 是 Pod 中 能 够 被 多 个 容器 访问 的 共 孚 目 未 。Kubernetes 的 
volume 概念、 用 途 和 目的 与 Docker 的 Volume 比 较 类 似 ， 但 两 者 不 能 等 
价 。 首 先 ，Kubernetes 中 的 Volume 定 义 在 Pod 上 ， 然 后 被 一 个 Pod 里 的 
多 个 容 需 挂 载 到 具体 的 文件 目 孙 下 ;， 其 次 ，Kubernetes 中 的 Volume 与 
Pod 的 生命 周期 相同 ， 但 与 容 絮 的 生命 周期 不 相关 ， 当 容 絮 终止 或 者 
重启 时 ，Volume 中 的 数据 也 不 会 丢失 。 最 后 ，Kubernetes 文 持 多 种 类 
型 的 Volume， 例 如 GlusterFS、Ceph 等 先进 的 分 布 式 文件 系统 。 


Volume 的 使 用 也 比较 简单 ， 在 大 多 数 情况 下 ， 我 们 先 在 Pod 上 声 
明 一 个 Volume， 然 后 在 容器 里 引用 该 Volume 并 Mount 到 容器 里 的 某 个 
目 孙 上 。 举 例 来 说 ， 我 们 要 给 之 前 的 Tomcat Pod 增 加 一 个 名 字 为 
datavol 的 Volume， 并 且 Mount 到 容器 的 /mydata-data 目 未 上， 则 只 要 对 
Pod 的 定义 文件 做 如 下 修正 即 可 (注意 黑体 字 部 分 ) : 


template: 
metadata: 
labels: 
app: app-demo 
tier: frontend 
spec: 
volumes: 
- name: datavol 


emptyDir: {} 


containers: 
- name: tomcat-demo 
image: tomcat 
volumeMounts: 
- mountPath: /mydata-data 
name: datavol 


imagePullPolicy: IfNotPresent 


除了 可 以 让 一 个 Pod 里 的 多 个 容器 共享 文件 、 让 容器 的 数据 写 到 
宿主 机 的 磁 弄 上 或 者 写 文件 到 网 络 存 储 中 ，Kubernetes 的 Volume 还 扩 
展 出 NU pci BIA SR RU eC ESE Hr GE X58 
H, 通过 ConfigMap 这 个 新 的 资源 对 象 来 实现 的 ， 后 面 我 们 会 详 
o 


Kubermnetes 提 供 了 非常 丰富 的 Volume 类 型 ， 下 面 逐 一 进行 说 明 。 


1.emptyDir 


一 个 emptyDir Volume 是 在 Pod 分 配 到 Node 时 创建 的 。 从 它 的 名 称 
就 可 以 看 出 ， 它 的 初始 内 容 为 室 ， 并 且 无 须 指定 答 主 机 上 对 应 的 目录 
文件 ， 因 为 这 是 Kubernetes 自 动 分 配 的 一 个 目录 ， 当 Pod 从 Node 上 移 除 
时 ，emptyDir 中 的 数据 也 会 被 永久 删除 。emptyDir 的 一 些 用 途 如 下 。 


临时 空间 ， 例 如 用 于 某 些 应 用 程序 运行 时 所 需 的 临时 目录 ， 且 无 
须 永久 保留 。 

长 时 间 任 务 的 中 间 过 程 CheckPoint 的 临时 保存 目录 。 

一 个 容器 需要 从 另 一 个 容器 中 获取 数据 的 目 孙 (多 容器 共享 目 
AX) ° 


目前 ， 用 户 无 法 控制 emptyDir 使 用 的 介质 种 类 。 如 果 kubelet 的 配 
置 是 使 用 硬盘 ， 那 么 所 有 emptyDir 都 将 创建 在 该 硬盘 上 。Pod 在 将 来 可 
以 设置 emptyDir 是 位 于 人 硬盘、 固态 人 硬盘 上 还 是 基于 内 存 的 tmpfs 上 ， 上 
面 的 例子 便 采 用 了 emptyDir 类 的 Volume ° 


2.hostPath 


hostPath 为 在 Pod 上 挂 载 和 宿主 机 上 的 文件 或 目录 ， 它 通常 可 以 用 于 
以 下 几 方 面 。 


。 容器 应 用 程序 生成 的 日 志文 件 需 要 永久 保存 时 ， 可 以 使 用 宿主 机 
的 高 速 文 件 系统 进行 存储 。 

。 需 要 访问 答 主 机 上 Docker 引 敬 内 部 数据 结构 的 容器 应 用 时 ， 可 以 
通过 定义 hostPath 为 答 主 机 /var/lib/docker 目 录 ， 使 容器 内 部 应 用 可 
以 直接 访问 Docker 的 文件 系统 。 


在 使 用 这 种 类 型 的 Volume 时 ， 需 要 注意 以 下 几 点 。 


。 在 不 同 的 Node 上 具有 相同 配置 的 Pod 可 能 会 因为 宿主 机 上 的 目 孙 
和 文件 不 同 而 导致 对 Volume 上 有 目 孙 和 文件 的 访问 结果 不 一 致 。 

。 如 果 使 用 了 资源 配额 管理 ， 则 Kubernetes 无 法 将 hostPath 在 宿主 机 
上 使 用 的 资源 纳入 管理 。 


在 下 面 的 例子 中 使 用 宿主 机 的 /data 目 录 定 义 了 一 个 hostPath 类 型 的 


Volume: 


volumes: 


- name: "persistent-storage" 


hostPath: 


path: "/data" 


3.gcePersistentDisk 


fE F] ik fp 2S 78 BJ Volume € zr [56 AA GB He AIK A 05 A 
(Persistent Disk, PD) 存放 Volume 的 数据 ， 它 与 EmptyDir 不 同 ，PD 
上 的 内 容 会 被 永久 保存 ， 当 Pod 被 删除 时 ，PD 只 是 被 卸载 
(Unmount) ， 但 不 会 被 删除 。 需 要 注意 的 是 ， 你 需要 先 创 建 一 个 永 
MEE (PD) ， 才 能 使 用 gcePersistentDisk ° 


使 用 gcePersistentDisk 有 以 下 一 些 限制 条 件 。 


e Node (运行 kubelet 的 节点 ) 需要 是 GCE 虚 拟 机 。 
。 这 些 虚 拟 机 需要 与 PD 存 在 于 相同 的 GCE 项 目 和 Zone 中 。 


通过 gcloud 命 令 即 可 创建 一 个 PD: 


gcloud compute disks create --size-500GB --zone-us- 


centrali-a my-data-disk 


定义 gcePersistentDisk 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- name: test-volume 
# This GCE PD must already exist. 


gcePersistentDisk: 


pdName: my-data-disk 


fsType: ext4 


4.awsElasticBlockStore 


与 GCE 类 似 ， 该 类 型 的 Volume 使 用 亚 马 进 公有 云 提 供 的 EBS 
Volume 存储 数据 ， 需 要 先 创 建 一 个 EBSVolume 才能 使 用 


awsElasticBlockStore ° 


使 用 awsElasticBlockStore 的 一 些 限制 条 件 如 下 。 


e Node (运行 kubelet 的 节点 ) 需要 是 AWS EC2 实 例 。 

。 这 些 AWS EC2 实 例 需 要 与 EBS volume 存 在 于 相同 的 region 和 
availability-zone 中 。 

。 EBS 只 支持 单个 EC2 实 例 mount 一 个 volume ° 


通过 aws ec2create-volume 命 令 可 以 创建 一 个 EBS volume: 


aws ec2 create-volume --availability-zone eu-west-1a - 


-Size 10 --volume-type gp2 


定义 awsElasticBlockStore 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- name: test-volume 
# This AWS EBS volume must already exist. 


awsElasticBlockStore: 


volumeID: aws://<availability-zone>/<volume-id> 


fsType: ext4 


5.NFS 
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系统 中 部 署 一 个 NFS Server。 定 义 NFS 类 型 的 Volume 的 示例 如 下 : 


volumes: 
- name: nfs 
nfs: 
# 改 为 你 的 NFS 服 务 器 地 址 
server: nfs-server.localhost 


path: "/" 


6. 其 他 类 型 的 Volume 


e iscsi: 使 用 iSCSI 存储 设备 上 的 目录 挂 载 到 Pod 中 。 

flocker: 使 用 Flocker 来 管理 存储 卷 。 

glusterfs: 使 用 开源 GlusterFS 网 络 文件 系统 的 目录 挂 载 到 Pod 中 。 

e rbd: 使 用 Linux 块 设备 共享 存储 (Rados Block Device) 挂 载 到 Pod 

中 o 

gitRepo: 通过 挂 载 一 个 空 目 录 ， 并 从 GIT 库 clone 一 个 git repository 

以 供 Pod 使 用 。 

。 secret: 一 个 secret volume 用 于 为 Pod 提 供 加 密 的 信息 ， 你 可 以 将 定 
义 在 Kubernetes 中 HY secret 直接 挂 载 为 文件 让 Pod 访 问 。secret 


volume 是 通过 tmfs (内 存 文件 系统 ) 实现 的 ， 所 以 这 种 类 型 的 
volume 总 是 不 会 持久 化 的 。 


1.4.10 Persistent Volume 


之 前 我 们 提 到 的 Volume 是 定义 在 Pod 上 的 ， 属 于 “计算 资源 ”的 一 
部 分 ， 而 实际 上 , “网 络 存储 ?是 相对 独立 于 “计算 资源 而 存在 的 一 种 
实体 资源 。 比 如 在 使 用 虚 机 的 情况 下 ， 我 们 通常 会 完 定义 一 个 网 络 存 
储 ， 然 后 从 中 划 出 一 个 “网 盘 * 并 挂 接 到 虚 机 上 。Persistent Volume (fj 
称 PV) 和 与 之 相关 联 的 Persistent Volume Claim (简称 PVC) 也 起 到 了 
类 似 的 作用 。 


PV 可 以 理解 成 Kubernetes 集 群 中 的 某 个 网 络 存储 中 对 应 的 一 块 存 
储 ， 它 与 Volume 很 类 似 ， 但 有 以 下 区 别 。 


。PV 只 能 是 网 络 存储 ， 不 属于 任何 Node， 但 可 以 在 每 个 Node 上 访 
问 。 

。 了 PV 并 不 是 定义 在 Pod 上 的 ， 而 是 独立 于 Pod 之 外 定义 。 

。PV 目 前 只 有 几 种 类 型 : GCE Persistent Disks ^ NFS ^ RBD ^ 
iSCSCI、AWS ElasticBlockStore、GlusterFS 等 。 


下 面 给 出 了 NFS 类 型 PV 的 一 个 yaml 定 义 文件 ， 声 明了 需要 5Gi 的 
存储 空间 : 


apiVersion: vi 
kind: PersistentVolume 
metadata: 


name: pv0003 


spec: 

Capacity: 

storage: 5Gi 
accessModes: 

- ReadWriteOnce 
nfs: 

path: /somepath 

server: 172.17.0.2 


比较 重要 的 是 PV 的 accessModes 必 性， 目前 有 以 下 类 型 。 


。 ReadWriteOnce: 读 写 权限 、 并 且 只 能 被 单个 Node 挂 载 。 
e ReadOnlyMany: 只 该 权限、 人 允许 被 多 个 Node 挂 载 。 
e ReadWriteMany: 读 写 权限 、 人 允许 被 多 个 Node 挂 载 。 


如 果 某 个 Pod 想 申请 某 种 条 件 的 PV， 则 首先 需要 定义 一 个 
PersistentVolumeClaim (PVC) 对 象 : 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: myclaim 
spec: 
accessModes: 
- ReadWriteOnce 
resources: 
requests: 


storage: 8Gi 


然后 ， 在 Pod 的 Volume 定 义 中 引用 上 述 PVC 即 可 : 


volumes: 
- name: mypd 
persistentVolumeClaim: 


claimName: myclaim 


最 后 ， 我 们 说 说 PV 的 状态 ，PV 是 有 状态 的 对 象 ， 它 有 以 下 几 种 


Available: 空闲 状态 。 

Bound: 已 经 绑 定 到 某 个 PVC 上 。 

Released: 对 应 的 PVC 已 经 删除 ， 但 资源 还 没有 被 集群 收回 。 
Failed: PV 自 动 回收 失败 。 


1.4.11 Namespace (命名 空间 ) 


Namespace (命名 空间 ) 是 Kubernetes 系 统 中 的 另 一 个 非常 重要 的 
概念 ，Namespace 在 很 多 情况 下 用 于 实现 多 租户 的 资源 隔离 。 
Namespace 通 过 将 集群 内 部 的 资源 对 象 “ 分 配 * 到 不 同 的 Namespace 中 ， 
形成 逻辑 上 分 组 的 不 同 项 目 、 小 组 或 用 户 组 ， 便 于 不 同 的 分 组 在 共享 
使 用 整个 集群 的 资源 的 同时 还 能 被 分 别管 理 。 


Kubernetes 集群 在 启动 后 ， 会 创建 一 个 名 为 “default” 的 
Namespace， 通 过 kubectl 可 以 查看 到 |: 


$ kubectl get namespaces 
NAME LABELS STATUS 


default <none> Active 


接 下 来 ， 如 果 不 特别 指明 Namespace， 则 用 户 创建 的 Pod、RC、 
Service 都 将 被 系统 创建 到 这 个 默认 的 名 为 default 的 Namespace 中 。 
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developmentH‘/Namespace ° 


apiVersion: vi 
kind: Namespace 
metadata: 


name: development 


一 旦 创建 了 Namespace， 我 们 在 创建 资源 对 象 时 就 可 以 指定 这 个 
资源 对 象 属于 哪个 Namespace。 比 如 在 下 面 的 例子 中 ， 我 们 定义 了 一 
个 名 为 busybox 的 Pod， 放 入 development 这 个 Namespace 里 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: busybox 
namespace: development 
spec: 
containers: 
- image: busybox 
command: 
- sleep 
- "3600" 


name: busybox 


此 时 ， 使 用 kubectl get 命 令 查 看 将 无 法 显示 : 


$ kubectl get pods 
NAME READY STATUS RESTARTS AGE 


这 是 因为 如 果 不 加 参数 ， 则 kubectl get fiy oH [X RB 
于 “default” 命 名 空间 的 资源 对 象 。 


可 以 在 kubectl 命 令 中 加 入 --namespace 参 数 来 查看 某 个 命名 空间 中 
的 对 象 : 


# kubectl get pods --namespace=development 
NAME READY STATUS RESTARTS AGE 


busybox 1/1 Running 0 1m 


当 我 们 给 每 个 租户 创建 一 个 Namespace 来 实现 多 租户 的 资源 隔离 
时 ， 还 能 结合 Kubernetes 的 资源 配额 管理 ， 限 定 不 同 租户 能 占用 的 资 
源 ， 例 如 CPU 使 用 量 、 内 存 使 用 量 等 。 关 于 资源 配额 管理 的 问题 ， 在 
后 面 的 革 广 中 会 详细 介绍 。 


1.4.12 Annotation (注解 ) 


Annotation 与 Label 类 似 ， 也 使 用 iiic 键 值 对 的 形式 进行 定 
义 。 不 同 的 是 Label 具 有 严格 的 命名 规则 ， 它 定义 的 是 Kubernetes 对 象 
的 元 数据 (Metadata) ， 并 且 用 于 Label Selector。 而 Annotation 则 是 用 
户 任意 定义 的 “附加 ”信息 ， 以 便于 外 部 工具 进行 查找 ， 很 多 时 候 ， 
Kubernetes 的 模块 自身 会 通过 Annotation 的 方式 标记 资源 对 象 的 一 些 特 
殊 信 息 。 


通 缘 来 说 ， 用 Annotation 来 记录 的 信息 如 下 。 


* buildf# A ^ release ($ Jd ^ Docker fi fa S, fil ADHI] EX ` 
release id 号 、PR 号 、 镜 像 hash 值 、docker registry 地 址 等 。 

。 日 志 库 、 监 探 库 、 分 析 库 等 资源 库 的 地 址 信息 。 

。 程序 调试 工具 信息 ， 例 如 工具 名 称 、 版 本 号 等 。 

。 团队 的 联系 信息 ， 例如 电话 号 码 、 人 负责 人 名 称 、 网 址 等 。 


191139 fin 


上 述 这 些 组 件 是 Kubernetes 系 统 的 核心 组 件 ， 它 们 共同 构成 了 
Kubernetes 系 统 的 框架 和 计算 模型 。 通 过 对 它们 进行 灵活 组 合 ， 用 户 
就 可 以 快速 、 方 便 地 对 容 怖 集群 进行 配置 、 创 建 和 管理 。 除 了 本 章 所 
介绍 的 核心 组 件 ， 在 Kubernetes 系 统 中 还 有 许多 辅助 配置 的 资源 对 
象 ， 例 如 LimitRange、ResourceQuota。 男 外 ， 一 些 系 统 内 部 使 用 的 对 
象 Binding、Event 等 请 参考 Kubernetes 有 的 API 义 档 。 


在 第 2 章 中 ， 我 们 将 开始 深入 实践 并 全 面 掌握 Kubernetes 的 各 种 使 
用 技巧 。 
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本 章 将 从 Kubernetes 的 系统 安装 开始 ， 逐 步 介 绍 Kubernetes 的 服务 
相关 配置 、 命 令 行 工具 kubect 的 使 用 详解 ， 然 后 通过 大 量 案例 实践 对 
Kubernetes 最 核心 的 容 毁 和 微服 务 架 构 的 概念 和 用 法 进行 详细 说 明 。 


2.1 Kubernetes 安 装 与 配置 


2.1.1 ”安装 Kubernetes 


Kubemetes 系 统 由 一 组 可 执行 程序 组 成 ， 用 户 可 以 通过 GitHub 上 
的 Kubemetes 项 目 页 下 载 编 译 好 的 二 进 制 包 ， 或 者 下 载 源 代码 并 编译 
后 进行 安装 。 


安装 Kubemetes 对 软件 和 硬件 的 系统 要 求 如 表 2.1 所 示 。 
表 2.1 ”安装 Kubernetes 对 软件 和 硬件 的 系统 要 求 


软 硬 件 最 低 配 置 推荐 配置 
CPU 和 内 存 | Master: 至 少 1 core 和 2GB 内 存 


Master: 2 core 和 4GB 内 存 

Node: 至 少 1core 和 2GB 内 存 Node: 由 于 要 运行 Docker， 所 以 应 根 
据 需 要 运行 的 容器 数量 进行 调整 
Linux 操作 | 基于 x86_64 架构 的 各 种 Linux 发 行 版 本 ， 包 括 Red Hat Linux, | Red Hat Linux 7 

系统 CentOS, Fedora, Ubuntu 等 ，Kemel 版 本 要 求 在 3.10 及 以 上 。 CentOS 7 

也 可 以 在 谷歌 的 GCE(Google Compute Engine ) 或 者 Amazon fÉ] AWS 
(Amazon Web Service) 云 平 台 上 进行 安装 


ik 硬 d 最 低 配 置 推荐 配置 
Docker 1.9 版 本 及 以 上 1.12 版 本 
下 载 和 安装 说 明 见 https://www.docker.com 


etcd 2.0 版 本 及 以 上 3.0 版 本 
下 载 和 安装 说 明 见 https://github.com/coreos/etcd/releases 


最 人 简单 的 安装 法 是 使 用 yum install kubernetes 命令 完成 
Kubernetes 集 群 的 安装 ， 但 仍 需 修 改 各 组 件 的 局 动 参数 ， 才 能 完成 
ee o 


a 
Ni 


本 章 以 二 进 制 文 件 和 手工 配置 启动 参数 的 形式 进行 安装 ， 对 每 个 
组 件 的 配置 进行 详细 说 明 。 


从 Kubernetes 官 网 下 载 编译 好 的 二 进 制 包 ， 如 图 2.1 所 示 ， 下 载 地 
HE 为 https://github.com/kubernetes/kubernetes/releases 。 本 书 基 于 
Kubernetes 1.3 版 本 进行 说 明 。 


v1.3.0 


QE david-mcmahon released this on 2 Jul - 179 commits to release-1.3 since this release 


See kubernetes-announce@ and CHANGELOG for details. 


Downloads 


T kubernetes.tar.gz 


2.1 GitHub 上 Kubernetes 的 下 载 页 面 


在 压缩 包 kubernetes.tar.gz 内 包含 了 Kubernetes 的 服务 程序 文件 、 文 
档 和 示例 o 


解压 缩 后 ，server 子 目录 中 的 kubernetes-server-linux-amd64.tar.gz 文 
件 包 含 了 Kubernetes 需 要 运行 的 全 部 服务 程序 文件 。 服 务 程序 文件 列 
表 如 表 2.2 所 示 。 


X22 服务 程序 文件 列表 


hyperkube 总 控 程 序 ， 用 于 运行 其 他 Kubemetes 程序 


kube-apiserver apiserver 主 程序 


kube-apiserver.docker_tag apiserver docker 镜像 的 tag 


kube-apiserver.tar apiserver docker 镜像 文件 


kube-controller-manager controller-manager 主 程序 


kube-controller-manager.docker tag controller-manager docker 镜像 的 tag 


kube-controller-manager.tar controller-manager docker 镜像 文件 


kubectl 客户 端 命令 行 工具 


kubelet kubelet 主 程序 


kube-proxy proxy 主 程序 


kube-scheduler scheduler 主 程序 


kube-scheduler.docker_tag scheduler docker 镜像 的 tag 


kube-scheduler.tar scheduler docker 镜像 文件 


Kubernetes Master “J 点 安装 部 署 etcd ^ kube-apiserver ^ kube- 
controller-manager ` kube-scheduler fk 25 #2 » RAME H kubectl E 23 zx 
户 端 与 Master 进 行 交 互 操 作 ， 在 工作 Node 上 仪 需 部 署 kubelet 和 kube- 
proxy 服 务 进 程 。Kubernetes 还 提供 了 一 个 “all-in-one” 的 hyperkube 程 序 
来 完成 对 以 上 服务 程序 的 启动 。 


2.1.2 配置 和 局 动 Kubernetes 服 务 


Kubernetes 的 服务 都 可 以 通过 直接 运行 二 进 制 文件 加 上 局 动 参数 
完成 。 为 了 便于 管理 ， 常 见 的 做 法 是 将 Kubernetes 服 务 程序 配置 为 
Linux 的 系统 开机 上 自动 启动 的 服务 。 


ÆT DA CentOS Linux 7 为 例 ， 使 用 Systemd 系 统 完成 Kubernetes 服 
务 的 配置 。 其 他 Linux 发 行 版 的 服务 配置 请 参考 相关 的 系统 管理 手册 。 


需要 注意 的 是 ，CentOS Linux 7 默认 局 动 了 firewalld 一 一 防火 墙 服 
务 ， 而 Kubernetes 的 Master 与 工作 Node 之 间 会 有 大 量 的 网 络 通 信 ， 安 全 
的 做 法 是 在 防火 墙 上 配置 各 组 件 需 要 相互 通信 的 端口 号 ， 具 体 要 配置 
的 端口 号 详 见 2.1.6 广 中 各 服务 监听 的 端口 号 说 明 。 在 一 个 安全 的 内 部 
网 络 环境 中 可 以 关闭 防火 墙 服务 : 


# systemctl disable firewalld 


# systemctl stop firewalld 


将 Kubernetes 的 可 执行 文件 复制 到 /usr/bin (如 果 复 制 到 其 他 目 
录 ， 则 将 systemd 服 务 文 件 中 的 文件 路 径 修 改正 确 即 可 ) ， 然 后 对 服务 
进行 配置 。 


在 下 面 的 服务 局 动 参数 说 明 中 主要 介绍 最 重要 的 局 动 参数 ， 每 个 
服务 的 启动 参数 还 有 很 多 ， 详 见 2.1.6 节 的 完整 说 明 。 有 兴趣 的 读者 可 
以 演 试 修改 它们 ， 以 观察 服务 运行 的 不 同 效果 。 


1.Master E HJetcd ` kube-apiserver ^ kube-controller-manager ^ kube- 


scheduler 服 务 
1) etcd 服 务 


etcd 服 务 作 为 Kubernetes 集 群 的 主 数据 库 ， 在 安装 Kubernetes 各 服 
务 之 前 需要 首先 安装 和 启动 。 


从 GitHub 官 网 下 载 etcd 发 布 的 二 进 制 文件 ， 将 etcd 和 etcdctl 文 件 复 
制 全 /usr/bin 目 录 。 


设置 systemd 服 务 文件 /usr/lib/systemd/system/etcd.service: 


[Unit] 
Description=Etcd Server 


After=network.target 


[Service] 

Type=simple 
WorkingDirectory-/var/lib/etcd/ 
EnvironmentFile--/etc/etcd/etcd.conf 


ExecStart-/usr/bin/etcd 


[Install] 


WantedByzmulti-user.target 


其 中 WorkingDirectory (/var/lib/etcd/) 表示 etcd 数 据 保存 的 目录 ， 
需要 在 局 动 etcd 服 务 之 前 进行 创建 。 


配置 文件 /etc/etcd/etcd.conf 通 常 不 需要 特别 的 参数 设置 (详细 的 参 
数 配 置 内 容 参 见 官方 文档 ) ，etcd 默 认 将 监听 在 http://127.0.0.1: 2379 
地 址 供 客户 端 连 接 o 


配置 完成 后 ， 通 过 systemct start 命 令 启 动 etcd 服 务 。 同 时 ， 使 用 
systemctl enable 命 令 将 服务 加 入 开机 局 动 列表 中 : 


# systemctl daemon-reload 
# systemctl enable etcd.service 


# systemctl start etcd.service 


通过 执行 etcdctl cluster-health， 可 以 验证 etcd 是 否 正确 局 动 : 


# etcdctl cluster-health 
member ce2a822cea30bfca is healthy: got healthy result 
from http://127.0.0.1:2379 


cluster is healthy 


2) kube-apiserver 服 务 
将 kube-apiserver 的 可 执行 文件 复制 到 /usr/bin 目 录 。 


编 $$ systemd fk 务 X 4F  /usr/ib/systemd/system/kube- 
apiserver.service， 内 容 如 下 : 


[Unit] 


Description=Kubernetes API Server 


Documentation=https://github.com/GoogleCloudPlatform/kubern 
etes 
After=etcd.service 


Wants=etcd.service 


[Service] 
EnvironmentFile-/etc/kubernetes/apiserver 
ExecStart-/usr/bin/kube-apiserver $KUBE API ARGS 
Restart-on-failure 

Type=notify 


Limi tNOFILE=65536 


[Install] 


WantedBy=multi-user.target 


配置 文件 /etc/kubernetes/apiserver 的 内 容 包 括 了 kube-apiserver 的 全 
部 启动 参数 ， 主 要 的 配置 参数 在 变量 KUBE_API ARGS 中 指定 。 


# cat /etc/kubernetes/apiserver 

KUBE API ARGS-z'"--etcd servers-http://127.0.0.1:2379 -- 
insecure-bind-address-0.0.0.0 --insecure-port-8080 -- 
service-cluster-ip-range-169.169.0.0/16 - service-node- 
port-range-1-65535 -- 
admission control-zNamespaceLifecycle,LimitRanger,SecurityCo 
ntextDeny, ServiceAccount, ResourceQuota --logtostderr=false 


--log-dir=/var/log/kubernetes --v=2" 


对 局 动 参数 的 说 明 如 下 。 


--etcd_servers: 指定 etcd 服 务 的 URL 。 

--insecure-bind-address: apiserver 绑 定 主机 的 非 安 全 了 了 地址， 设置 
0.0.0.0 表 示 绑 定 所 有 IP 地 址 。 

--insecure-port: apiserver 绑 定 主 机 的 非 安 全 端口 号 ， 默 认为 
8080 ° 

--service-cluster-ip-range: Kubernetes 2 fff rP Service A’) fig FH IP HE HE 
段 范围 ， 以 CIDR 格 式 表 示 ， 例 如 169.169.0.0/16， 该 IP 范 围 不 能 
物理 机 的 真实 IP 段 有 重合 。 

--service-node-port-range: Kubernetes 集 群 中 Service 可 映射 的 物理 
机 端口 号 范围 ， 默 认为 30000~-32767 ° 

--admission_control: Kubernetes 集 群 的 准 入 控制 设置 ， 各 控制 模 
块 以 插件 的 形式 依次 生效 。 

--logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr 。 
--log-dir: 日 志 目 录 。 

--V: 日 志 级 别 。 


3) kube-controller-manager 服 务 


kube-controller-manager 服 务 依赖 于 kube-apiserver 服 务 。 


# cat /usr/lib/systemd/system/kube-controller- 
manager .service 
[Unit ] 


Description=Kubernetes Controller Manager 


Documentation=https://github.com/GoogleCloudPlatform/kubern 


etes 


After=kube-apiserver.service 


Requires=kube-apiserver.service 


[Service] 
EnvironmentFile-/etc/kubernetes/controller-manager 


ExecStart-/usr/bin/kube-controller-manager 
S$KUBE CONTROLLER MANAGER ARGS 


Restart-on-failure 


LimitNOFILE-65536 


[Install] 


WantedBy=multi-user. target 


fic EXC 4# /etc/kubernetes/controller-manager 的 内 容 包 括 了 kube- 
controller-manager 的 全 部 启动 参数 ， 主 要 的 配置 参数 在 变量 
KUBE_CONTROLLER_MANAGER_ARGS 中 指定 。 


# cat /etc/kubernetes/controller-manager 
KUBE CONTROLLER MANAGER ARGS-'-- 


master=http://192.168.18.3:8080 --logtostderr-false  --log- 


dir-/var/log/kubernetes --v=2" 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 
e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr 。 


e --log-dir: H m H 3K " 
e --V: 日 志 级 别 。 


4) kube-scheduler 服 务 


kube-scheduler 服 务 也 依赖 于 kube-apiserver 服 务 。 


# cat /usr/lib/systemd/system/kube-controller- 
manager .service 
[Unit] 


Description-Kubernetes Controller Manager 


Documentation-https://github.com/GoogleCloudPlatform/kubern 
etes 
After=kube-apiserver.service 


Requires=kube-apiserver.service 


[Service] 

EnvironmentFile-/etc/kubernetes/scheduler 
ExecStart-/usr/bin/kube-scheduler $KUBE SCHEDULER ARGS 
Restart-on-failure 


LimitNOFILE=65536 


[Install] 


WantedBy=multi-user. target 


配置 文件 /etc/kubernetes/scheduler 的 内 容 包 括 了 kube-scheduler 的 全 
部 启动 参数 ， 主 要 的 配置 参数 在 变量 KUBE_SCHEDULER_ARGS 中 指 


elt 


# cat /etc/kubernetes/scheduler 
KUBE_SCHEDULER_ARGS="- -master=http://192.168.18.3:8080 


--logtostderr=false --log-dir=/var/log/kubernetes --v=2" 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 

e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr * 
e --log-dir: Hi Hk» 

e --V: 日 志 级 别 。 


配置 完成 后 ， 执 行 systemctl start 命 令 按 顺序 启动 这 3 个 服务 。 同 
时 ， 使 用 systemctl enable 命 令 将 服务 加 入 开机 局 动 列 表 中 。 


systemctl daemon-reload 

systemctl enable kube-apiserver.service 
systemctl start kube-apiserver.service 
systemctl enable kube-controller -manager 
systemctl start kube-controller-manager 


systemctl enable kube-scheduler 


d + + + dto Gt OF 


systemctl start kube-scheduler 


JH 过 systemctl status<service_name> 来 验证 服务 的 局 动 状 
S, “ruming” KIRADI ° 


到 此 ，Master 上 所 需 的 服务 就 全 部 局 动 完 成 了 。 


2.Node 上 的 kubelet、kube-proxy 服 务 


在 工作 Node 方 点 上 需要 预先 安装 好 Docker Daemon7f E 1E % Ji 
动 。Docker 的 安装 详 见 http:/www.dockercom 的 说 明 ° 


1) kubelet 服 务 


kubelet 服 务 依赖 于 Docker 服 务 。 


# cat /usr/lib/systemd/system/kubelet.service 
[Unit ] 


Description=Kubernetes Kubelet Server 


Documentation=https://github.com/GoogleCloudPlatform/kubern 
etes 
After=docker.service 


Requires=docker.service 


[Service] 
WorkingDirectory-/var/lib/kubelet 
EnvironmentFile-/etc/kubernetes/kubelet 
ExecStart-/usr/bin/kubelet $KUBELET ARGS 


Restart-on-failure 


[Install] 


WantedBy=multi-user.target 


其 中 WorkingDirectory 表 示 kubelet 保 存 数 据 的 目 孙 ， 需 要 在 启动 


kubelet 服 务 之 前 进行 创建 。 


配置 文件 /etc/kubernetes/kubelet 的 内 容 包 括 了 kubelet 的 全 部 启动 参 
主要 的 配置 参数 在 变量 KUBELET_ARGS 中 指定 。 


# cat /etc/kubernetes/kubelet 
KUBELET ARGS-"--api-servers-http://192.168.18.3:8080 - 
-hostname-override-192.168.18.3 --logtostderr=false --1log- 


dir-/var/log/kubernetes --v=2" 


对 局 动 参数 的 说 明 如 下 。 


--api-servers: 指定 apiserver 的 URL 地 址 ， 可 以 指定 多 个 。 
--hostname-override: 设置 本 Node 的 名 称 。 

--logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr。 
-log-dir: HHX ° 

--V: 日 志 级 别 。 


2) kube-proxy 服 务 


kube-proxy 服 务 依赖 于 network 服 务 。 


[Unit] 


Description=Kubernetes Kube-Proxy Server 


Documentation=https://github.com/GoogleCloudPlatform/kubern 


etes 


After=network.target 


Requires=network.service 


[Service] 
EnvironmentFile-/etc/kubernetes/proxy 
ExecStart-/usr/bin/kube-proxy $KUBE PROXY ARGS 
Restart-on-failure 


LimitNOFILE-65536 


[Install] 


WantedByzmulti-user.target 


配置 文件 /etc/kubernetes/proxy 的 内 容 包 括 了 kube-proxy 的 全 部 启动 
参数 ， 主 要 的 配置 参数 在 变量 KUBE_PROXY_ARGS 中 指定 。 


# cat /etc/kubernetes/proxy 
KUBE_PROXY_ARGS="--master=http://192.168.18.3:8080 -- 


logtostderr=false --log-dir=/var/log/kubernetes --v=2" 


对 局 动 参数 的 说 明 如 下 。 


e --master: 指定 apiserver 的 URL 地 址 。 

e --logtostderr: 设置 为 false 表 示 将 日 志 写 入 文件 ， 不 写 入 stderr ° 
e --log-dir: His Ax ° 

e --V: 日 志 级 别 。 


配置 完成 后 ， 通 过 systemctl 启 动 kubelet 和 kube-proxy 服 务 : 


systemctl daemon-reload 
systemctl enable kubelet.service 
systemctl start kubelet.service 


systemctl enable kube-proxy 


+ + + + T+ 


systemctl start kube-proxy 


kubelet A iA Æ FH [5] Master El IIE dt E Node AL, 4 Master E & 
看 各 Node 的 状态 ， 状 态 为 Ready 表 示 Node 已 经 成 功 注 册 并 且 状 态 为 可 
用 o 


# kubectl get nodes 
NAME STATUS AGE 
192.168.18.3 Ready im 


等 所 有 Node 的 状态 都 为 Ready 之 后 ， 一 个 Kubernetes 集 群 束 启动 完 
成 了 。 接 下 来 就 可 以 创建 Pod、RC、Service 等 资源 对 象 来 部 署 Docker 
ae LA T ° 


2.1.3 Kubernetes 集 群 的 安全 设置 


1. 基 于 CA 等 名 的 双 回 数字 证 书 认证 方式 


在 一 个 安全 的 内 网 环境 中 ，Kubernetes 的 各 个 组 件 与 Master 之 间 可 
以 通过 apiserver 的 非 安 全 端口 http:Wapiserver: 8080 进 行 访问 。 但 如 果 
apiserver 需 要 对 外 提供 服务 ， 或 者 集群 中 的 菜 些 容器 也 需要 访问 
apiserver 以 获取 集群 中 的 某 些 信息 ， 则 更 安全 的 做 法 是 启用 HTTPS 安 
全 机 制 。Kubermnetes 提 供 了 基于 CA 签名 的 双 同 数字 证 书 认 证 方式 和 简 
单 的 基于 HTTP BASE 或 TOKEN 的 认证 方式 ， 其 中 CA 证 书 方式 的 安全 
性 最 高 。 本 节 先 介绍 以 CA 证 书 的 方式 配置 Kubernetes 集 群 ， 要 求 
Master 上 的 kube-apiserver ^ kube-controller-manager ` kube-scheduleri# 
程 及 各 Node 上 的 kubelet、kube-proxy 进 程 进 行 CA 签 名 双 辣 数字 证 书 安 
全 设置 。 


基于 CA 等 名 的 双 回 数字 证 书 的 生成 过 程 如 下 。 


(1) 为 kube-apiserver 生 成 一 个 数字 证 书 ， 并 用 CA 证 书 进 行 签 
名 o 


(2) 为 kube-apiserverj 进 程 配置 证 书 相 关 的 启动 参数 ， 包 括 CA 证 
书 《用 于 验证 客户 端 证 书 的 签名 真 伪 ) 、 和 上 自己 的 经 过 CA 签名 后 的 证 书 
及 私 钥 。 


(3) 为 每 个 访问 Kubernetes API Server 的 客户 端 ( 40 kube- 
controller-manager ^ kube-scheduler ^ kubelet ^ kube-proxy 及 调用 API 


Server 的 客户 端 程序 kubectl 等 ) 进程 生成 自己 的 数字 证 书 ， 也 都 用 CA 
证 书 进行 签名 ， 在 相关 程序 的 启动 参数 里 增加 CA 证 书 、 上 自己 的 证 书 等 
相关 参数 。 


1) 设置 kube-apiserver 的 CA 证 书 相 关 的 文件 和 启动 参数 


使 用 OpenSSL 工 具 在 Master 服 务 器 上 创建 CA 证 书 和 私 钥 相 关 的 文 
件 : 


# openssl genrsa -out ca.key 2048 
# openssl req -x509 -new -nodes -key ca.key -subj 
"/CN=yourcompany.com" -days 5000 -out ca.crt 


# openssl genrsa -out server.key 2048 


注意 : 生成 ca.crt 时 ，-subj 参 数 中 ”CN” 的 值 通常 为 域名 。 


准备 master_ssl.cnf 文 件 ， 该 文件 用 于 x509v3 版 本 的 证 书 。 在 该 文 

件 中 主要 需要 设置 Master 服 务 器 的 hostname (k8s-master) 、IP 地 址 

(192.168.18.3) ， 以 及 Kubernetes Master Service 的 虚拟 服务 名 称 

( kubernetes.default 等 ) 和 该 虚拟 服务 的 ClusterP 地 址 
(169.169.0.1) ° 


master_ssl.cnf 文 件 的 示例 如 下 : 


[req] 
req_extensions = v3_req 
distinguished name = req distinguished name 


[req distinguished name] 


[ v3_req ] 


basicConstraints = CA:FALSE 


keyUsage nonRepudiation, digitalSignature, 
keyEncipherment 

subjectAltName = @alt_names 

[alt names] 

DNS.1 - kubernetes 

DNS.2 - kubernetes.default 

DNS.3 - kubernetes.default.svc 


DNS.4 - kubernetes.default.svc.cluster.local 


DNS.5 - k8s-master 


IP.1 169.169.0.1 


IP.2 


192.168.18.3 


基于 master_ssl.cnf 创 建 server.csr 和 server.crt 文 件 。 在 生成 server.csr 
时 ，-subj 参 数 中 “%CN” 指 定 的 名 字 需 为 Master 所 在 的 主机 各 。 


# openssl req -new -key server.key -Subj "/CN=k8s- 
master" -config master_ssl.cnf -out server.csr 

# openssl x509 -req -in server.csr -CA ca.crt -CAkey 
ca.key -CAcreateserial -days 5000 -extensions v3 req - 


extfile master_ssl.cnf -out server.crt 


全 部 执行 完 后 会 生成 6 个 文件 : ca.crt ^ ca.key ^ ca.srl ^ server.crt ^ 


Server.csr ^ server.key ? 


将 这 些 文件 复制 到 一 个 目录 中 (例如 /var/run/kubernetes/) ， 然 后 
设置 kube-apiserver 的 三 个 启动 参数 “--client-ca-file”--tls-cert-file” 和 “-- 
tls-private-key-file”， 分 别 代 表 CA 根 证 书 文件 、 服 务 端 证 书 文件 和 服务 
端 私 钥 文件 : 


--client_ca_file=/var/run/kubernetes/ca.crt 
--tls-private-key-file-/var/run/kubernetes/server.key 


--tls-cert-file-/var/run/kubernetes/server.crt 


同时 ， 可 以 关 掉 非 安全 端口 8080， 设 置 安全 端口 为 443 (默认 为 


6443) 


--insecure-port=0 


--secure-port=443 


最 后 重启 kube-apiserver 服 务 。 
2) 设置 kube-controller-manager 的 客户 端 证 书 、 私 铀 和 局 动 参数 


$ openssl genrsa -out cs_client.key 2048 
$ openssl req -new -key cs_client.key -subj "/CN=k8s- 
node-1" -out cs client.csr 
$ openssl x509 -req -in cs client.csr -CA ca.crt - 


CAkey ca.key -CAcreateserial -out cs client.crt -days 5000 


其 中 ， 在 生成 cs_dlient.crt 时 ，-CA 参 数 和 -CAkey 参 数 使 用 的 是 
apiserver 的 ca.crt 和 ca.key 文 件 。 然 后 将 这 些 文件 复制 到 一 个 目录 中 ( 例 


如 /varrun/kubernetes/) ° 


fee 下 Æ 8) Æ /etc/kubernetes/kubeconfig X. fF ( kube-controller- 
manager kube-schedulerZ£ Hi) ， 配 置 客户 端 证 书 等 相关 参数 ， 内 容 
如 下 : 


apiVersion: v1 
kind: Config 
users: 
- name: controllermanager 
user: 
client-certificate: 
/var/run/kubernetes/cs_client.crt 
client-key: /var/run/kubernetes/cs_client.key 
clusters: 
- name: local 
cluster: 
certificate-authority: /var/run/kubernetes/ca.crt 
contexts: 
- context: 
cluster: local 
user: controllermanager 
name: my-context 


current-context: my-context 


然后 ， 设 置 kube-controller-manager 服 务 的 启动 参数 ， 注 意 ，-- 


master 的 地 址 为 HITPS 安 全 服务 地 址 ， 不 使 用 非 安 全 地 址 
http://192.168.18.3: 8080 ° 


--master=https://192.168.18.3:443 


service_account_private_key_file=/var/run/kubernetes/server 
. key 
--root-ca-file=/var/run/kubernetes/ca.crt 


- -kubeconfig-/etc/kubernetes/kubeconfig 


Æ ci kube-controller-manager]l 2$. ° 
3) 设置 kube-scheduler 启 动 参数 


kube-scheduler 复 用 上 一 步 kube-controller-manager 创 建 的 客户 端 证 
TB. BOUES: 


--master=https://192.168.18.3:443 


--kubeconfig=/etc/kubernetes/kubeconfig 


重启 kube-scheduler 服 务 。 
4) 设置 每 台 Node 上 kubelet 的 客户 疹 证 书 、 私 铀 和 局 动 参 老 


首先 复制 kube-apiserver 的 ca.crt 和 cakey 文 件 到 Node 上， 在 生成 
kubelet_client.crt 时 -CA 参数 和 -CAkey 参 数 使 用 的 是 apiserver 的 ca.crt 和 
ca.key 文 件 。 在 生成 kubelet_client.csr 时 -subj 参 数 中 的 “CN” 设 置 为 本 
Node 的 卫 地 址 。 


$ openssl genrsa -out kubelet_client.key 2048 


$ openssl req -new -key kubelet client.key -subj 


"/CN=192.168.18.4" -out kubelet_client.csr 
$ openssl x509 -req -in kubelet_client.csr -CA ca.crt 


-CAkey ca.key -CAcreateserial -out kubelet_client.crt -days 


5000 


将 这 些 文件 复制 到 一 个 目录 中 (例如 /var/run/kubernetes/) ° 


接 下 来 创建 /etc/kubernetes/kubeconfig 文 件 (kubelet 和 kube-proxy 进 


程 共 用 ) ， 配 置 客户 端 证 书 等 相关 参数 ， 内 容 如 下 : 


apiVersion: v1 
kind: Config 
users: 
- name: kubelet 
user: 
client-certificate: 
/etc/kubernetes/ssl_keys/kubelet_client.crt 
client-key: 
/etc/kubernetes/ssl_keys/kubelet_client.key 
clusters: 
- name: local 
cluster: 
certificate-authority: 
/etc/kubernetes/ssl_keys/ca.crt 
contexts: 
- context: 


cluster: local 


user: kubelet 
name: my-context 


current-context: my-context 


然后 ， 设 置 kubelet 服 务 的 启动 参数 : 


--api_servers=https://192.168.18.3:443 


- -kubeconfig-/etc/kubelet/kubeconfig 


最 后 重启 kubelet 服 务 。 
5) 设置 kube-proxy 的 启动 参数 


kube-proxy 复 用 上 一 步 kubelet 创 建 的 客户 端 证 书 ， 配 置 局 动 参 


--master=https://192.168.18.3:443 


- -kubeconfig-/etc/kubernetes/kubeconfig 


重启 kube-proxy 服 务 。 


至 此 ， 一 个 基于 CA 的 双 癌 数字 证 书 认 证 的 Kubernetes 集 群 环境 就 
搭建 完成 了 。 

6) 设置 kubectl 客 户 端 使 用 安全 方式 访问 apiserver 

在 使 用 kubecd 对 Kubernetes 集 群 进行 操作 时 ， 默 认 使 用 非 安 全 端口 


8080 对 apiserver 进 行 访 问 ， 也 可 以 设置 为 安全 访问 apiserver 的 模式 ， 需 
要 设置 3 个 证 书 相 关 的 参数 “一 certificate-authority”“--client- 


certificate”" 和 “--client-key”， 分 别 表示 用 于 CA 授权 的 证 书 、 客 户 端 证 书 
和 客户 端 密 钥 。 


e --certificate-authority: 使 用 为 kube-apiserver 生 成 的 ca.crt 文 件 。 

e --client-certificate : 使 用 7j kube-controller-manager ^E 成 的 
cs_client.crt 文 件 。 

e --client-key: 使 用 为 kube-controller-manager 生 成 的 cs_client.key 文 
件 。 


同时 ， 指 定 apiserver 的 URL 地 址 为 HTTPS 安 全 地 址 (例如 
https://k8s-master: 443) ， 最 后 输入 需要 执行 的 子 命令 ， 即 可 对 
apiserver 进 行 安 全 访问 了 : 


4  kubectl  --server-https://k8s-master:443 -- 
certificate-authority-/etc/kubernetes/ssl keys/ca.crt -- 


client-certificate-/etc/kubernetes/ssl keys/cs client.crt - 


-client-key-/etc/kubernetes/ssl keys/cs client.key get 
nodes 

NAME STATUS AGE 

k8s-node-1 Ready 1h 


2. 基 于 HTTP BASE 或 TOKEN 的 简单 认证 方式 


除了 基于 CA 的 双 回 数字 证 书 认证 方式 ，Kubernetes 也 提供 了 基于 
HTTP BASE 或 TOKEN 的 简单 认证 方式 。 各 组 件 与 apiserver 之 间 的 通信 
方式 仍然 采用 HTTPS， 但 不 使 用 CA 数字 证 书 。 


采用 基于 HTTP BASE 或 TOKEN 的 简单 认证 方式 时 ，API Server 对 
外 骏 露 HTTPS 端 口 ， 客 户 端 提 供用 户 名 、 蜜 码 或 Token 来 完成 认证 过 
程 。 需 要 说 明 的 是 ，kubectl 命 令 行 工具 比较 特殊 ， 它 同时 支持 CA 双 辐 
认证 与 简单 认证 两 种 模式 与 apiserver 通 信 ， 其 他 客户 端 组 件 只 能 配置 
为 双 回 安全 认证 或 非 安全 模式 与 apiserver 通 信 


基于 HTTP BASE 认 证 的 配置 过 程 如 下 。 


(1) 创建 包括 用 户 名 、 密 码 和 UID 的 文件 basic auth file, S ETE 
合适 的 目录 中 ， 例 如 /etc/kuberntes 目 隶 。 需 要 注意 的 是 ， 这 是 一 个 纯 
文本 文件 ， 用 户 名 、 密 码 都 是 明文 。 


# Vi /etc/kubernetes/basic auth file 
admin, admin, 1 


system, system, 2 


(2) 设置 kube-apiserver 的 启动 参数 “--basic_auth_file”， 使 用 上 述 
文件 提供 安全 认证 : 


--Secure-port=443 


--basic_auth_file=/etc/kubernetes/basic_auth_file 


然后 ， 重 启 API Server 服 务 » 


(3) 使 用 kubectl 通 过 指定 的 用 户 名 和 密码 来 访问 API Server: 


# kubectl --server=https://192.168.18.3:443 -- 


username=admin - password-admin --insecure-skip-tls- 


verify=true get nodes 


基于 TOKEN 认 证 的 配置 过 程 如 下 。 


(1) 创建 包括 用 户 名 、 密 码 和 UID 的 文件 token auth file, WE 
在 合适 的 目 孙 中 ， 例 如 /etckuberntes 目 示 。 需 要 注意 的 是 ， 这 是 一 个 
纯 文 本 文件 ， 用 户 名 、 密 码 都 是 明文 。 


$ cat /etc/kubernetes/token_auth_file 
admin, admin, 1 


system, system, 2 


(2) 设置 kube-apiserver 的 启动 参数 “--token_auth_file”， 使 用 上 述 
文件 提供 安全 认证 : 


--Secure-port=443 


--token_auth_file=/etc/kubernetes/token_auth_file 


SRG, ELIA API Server 服 务 。 
(3) 用 curl 验 证 和 访问 API Server: 


$ curl -k --header "Authorization:Bearer admin" 
https://192.168.18.3:443/version 
{ 
"major": "1", 
"minor": "3", 


"gitVersion": "v1.3.3", 


"gitCommit": 
"c6411395e09da356c608896d3d9725acab821418", 
"gitTreeState": "clean", 
"buildDate": "2016-07-22T20:22:25Z", 
"goVersion": "go1.6.2", 
"compiler": "gc", 


"platform": "linux/amde4" 


2.1.4 Kubernetes 的 版 本 升级 


Kubemetes 的 版 本 升级 需要 考虑 到 当前 集群 中 正在 运行 的 容器 不 
受 影响 。 应 对 集群 中 的 各 Node 逐 个 进行 隔离 ， 然 后 等 待 在 其 上 运行 的 


容 丹 全 部 执行 完成 ， 再 更 新 该 Node 上 的 kubelet 和 kube-proxy 服 务 ， 将 
全 部 Node 都 更 靳 完成 后 ， 最 后 更 新 Master 的 服务 。 


。 通 过 官网 获取 最 新 版 本 的 二 进 制 包 kubernetes.targz， 解 压缩 后 提 
取 服 务 二 进 制 文件 。 

。 逐个 隔离 Node， 等 竺 在 其 上 运行 的 全 部 容器 工作 完成 ， 更 新 
kubelet 和 kube-proxy 服 务 文件 ， 然 后 重 局 这 两 个 服务 。 


。 更 新 Master 的 kube-apiserver 、 kube-controller-manager 、 kube- 


scheduler 服 务 文件 并 重启 。 


2.1.5 内 网 中 的 Kubernetes 相 关 配 置 


Kubernetes 在 能 够 访问 Internet 网 络 的 环境 中 使 用 起 来 非常 方便 ， 
一 方面 在 docker.io 和 gcr.io 网 站 中 己 经 存在 了 大 量 官方 制作 的 Docker 镜 
像 ， 男 一 方面 GCE、AWS 提 供 的 云 平 台 已 经 很 成 熟 了 ， 用 户 通 过 租用 
一 定 的 空间 来 部 署 Kubernetes 集 群 也 很 徐 便 。 


但 是 ， 许 多 企业 内 部 由 于 安全 性 的 原因 无 法 访问 Internet。 对 于 这 
些 企业 吏 需 要 通过 创建 一 个 内 部 的 私有 Docker Registry， 并 修改 一 些 
Kubernetes 的 配置 ， 来 启动 内 网 中 的 Kubernetes 集 群 。 


1.Docker Private Registry 《私有 Docker 镜 像 库 ) 

使 用 Docker 提 供 的 Registry 镜 像 创 建 一 个 私有 镜像 仓库 。 

详细 的 安 步骤 请 参考 Docker 的 官方 文档 
PN NND NUR NÉ 


2.kubelet/ir & 


由 于 在 Kubernetes 中 是 以 Pod 而 不 是 Docker 容 器 为 管理 单元 的 ， 在 
kubelet 创 建 Pod 时 ， 还 通过 局 动 一 个 名 为 google_containers/pause 的 镜像 
来 实现 Pod 的 概念 。 


该 镜像 存在 于 谷歌 镜像 库 http:/gcrio 中 ， 需 要 通过 一 台 能 够 连 上 
Internet 的 服务 硕 将 其 下 载 ， 导 出 文件 ， 再 push 到 私有 Docker Registry 
HU o 


之 后 ， 可 以 给 每 台 Node 的 kubelet 服 务 的 启动 参数 加 上 -- 
pod infra container image 参数， 指定 为 私有 Docker Registry 中 pause 镜 
像 的 地 址 。 例 如 : 


# cat /etc/kubernetes/kubelet 

KUBELET_ARGS="--api-servers=http://192.168.18.3:8080 - 
-hostname-override=192.168.18.3 - -log- 
dir=/var/log/kubernetes --V=2 -- 
pod infra container image-gcr.io/google containers/pause- 


amd64:3.0" 


如 果 该 镜像 无 法 下 载 ， 则 也 可 以 从 Docker Hub 上 进行 下 载 : 


# docker pull kubeguide/google_containers/pause- 


amd64:3.0 


修改 kubelet 配 置 文件 中 的 


pod_infra_container_image 参 数 如 下 : 


pod infra container image-kubeguide/google containers/pause 


-amd64:3.0 


然后 重启 kubelet 服 务 : 


# systemctl restart kubelet 


通过 以 上 设置 束 在 内 网 环境 中 搭建 了 


一 个 企业 内 部 的 私有 容器 


2.1.66 Kubernetes 核 心服 务 配置 详解 


我 们 在 2.1.2 节 对 Kubernetes 各 服务 启动 进程 的 关键 配置 参数 进行 
了 简要 说 明 ， 实 际 上 Kubermetes 的 每 个 服务 都 提供 了 许多 可 配置 的 参 
数 。 这 些 参数 涉及 安全 性 、 性 能 优化 及 功能 扩展 (Plugin) 等 方 方 面 
面 。 全 面 理 解 和 掌握 这 些 参数 的 含义 和 配置 ， 无 论 对 于 Kubemetes 的 
生产 部 署 还 是 日 常 运 维 都 有 很 好 的 帮助 。 


每 个 服务 的 可 用 参数 都 可 以 通过 运行 “cmd--help” 命 令 进行 查看 ， 
其 中 cmd 为 具体 的 服务 启动 命令 ， 例 如 kube-apiserver ` kube-controller- 
manager ^ kube-scheduler 、kubelet、kube-proxy 等 。 男 外 ， 也 可 以 通过 
在 命令 的 配置 文件 (例如 /etc/kubernetes/kubelet 等 ) 中 添加 “-- 参 数 名 = 
参数 取 值 ”的 语句 来 完成 对 某 个 参数 的 配置 。 


本 市 将 对 Kubernetes 所 有 服务 的 参数 进行 全 面 介绍 ， 为 了 方便 学 
习 和 查阅 ， 对 每 个 服务 的 参数 用 一 个 小 市 进行 评 细 说 明 。 
1. 公 共 配 置 参数 


公共 配置 参数 适用 于 所 有 服务 ， 如 表 2.3 所 示 的 参数 可 用 于 kube- 
apiserver ^ kube-controller-manager ^ kube-scheduler ^ kubelet ^ kube- 
proxy。 本 节 对 这 些 参数 进行 统一 说 明 ， 不 再 在 每 个 服务 的 参数 列表 中 
列 出 。 


R23 ”公共 配置 参数 表 


参数 名 和 取 值 示例 


说 —H 


--log-backtrace-at=:0 


记录 日 志 每 到 “file: 行 号 ”时 打印 一 次 stack trace 


--log-dir= 


日 志文 件 路 径 


--log-flush-frequency=5s 


设置 flush 日 志文 件 的 时 间 间 隔 


--logtostderr-true 


参数 名 和 取 值 示例 


Hp 


设置 为 true 则 表示 将 日 志 输出 到 stderr， 不 输出 到 日 志文 件 


说 ĦA 


--alsologtostderr=false 


设置 为 tue 则 表示 将 日 志 输出 到 文件 的 同时 输出 到 stderr 


--stderrthreshold=2 


将 该 threshold 级 别 之 上 的 日 志 输 出 到 stderr 


--v=0 


glog 日 志 级 别 


--vmodule= 


glog 基于 模块 的 详细 日 志 级 别 


--version=[false] 


2.kube-apiserver 启 动 参 类 


设置 为 true 则 将 打印 版 本 信息 然后 退出 


对 kube-apiserver 启 动 参 数 的 详细 说 明 如 表 2.4 所 示 。 


表 2.4 ”对 kube-apiserver 启 动 参数 的 详细 说 明 


参数 名 和 取 值 示例 说 了 明 
--admission-control="AlwaysAdmit" 对 发 送 给 API Server 的 任何 请 求 进行 准 入 控制 ， 配 置 为 一 个 “ 准 入 控制 器 ”的 列 
dé, 多 个 准 入 控制 器 时 以 逗号 分 隔 。 多 个 准 入 控制 器 将 按 顺序 对 发 送 给 API Server 
的 请 求 进行 拦截 和 过 滤 ， 若 某 个 准 入 控制 器 不 允许 该 请 求 通过 ， 则 APT Server 拒 
绝 此 调用 请 求 。 可 配置 的 准 入 控制 器 如 下 。 
AlwaysAdmit: 允许 所 有 请 求 。 
AlwaysPullImages: 在 启动 容器 之 前 总 是 去 下 载 镜像 ,相当 于 在 每 个 容器 的 配 
置 项 imagePullPolicy=Always。 
AlwaysDeny: 禁止 所 有 请 求 ， 一 般 用 于 测试 。 
DenyExecOnPrivileged: 它 会 拦截 所 有 想 在 privileged container 上 执行 命令 的 
请 求 。 如 果 你 的 集群 支持 privileged container， 你 又 希望 限制 用 户 在 这 些 
privileged container 上 执行 命令 ， 那 么 强烈 推荐 你 使 用 它 。 
ServiceAccount: 这 个 plug-in 将 serviceAccounts 实现 了 自动 化 ， 如 果 你 想 要 
使 用 ServiceAccount 对 象 ， 那 么 强烈 推荐 你 使 用 它 。 
SecurityContextDeny: 这 个 插件 将 使 用 了 SecurityContext 的 Pod 中 定义 的 选 
项 全 部 失效 。SecurityContext 在 container 中 定义 了 操作 系统 级 别 的 安全 设 定 
(uid, gid, capabilities, SELinux 等 )。 
ResourceQuota: 用 于 配额 管理 目的 ， 作 用 于 Namespace 上 ， 它 会 观察 所 有 的 
请 求 , 确保 在 namespace 上 的 配额 不 会 超标 。 推 荐 在 admission control 参数 列 
表 中 这 个 插件 排 最 后 一 个 。 
LimitRanger: 用 于 配额 管理 ,作用 于 Pod 与 Container 上 ,确保 Pod 与 Container 
上 的 配额 不 会 超标 。 
NamespaceExists (已 过 时 ): 对 所 有 请 求 校 验 namespace 是 否 已 存在 ， 如 果 不 
存在 则 拒绝 请 求 。 已 合并 至 NamespaceLifecycle。 
NamespaceAutoProvision (已 过 时 ): 对 所 有 请 求 校 验 namespace， 如 果 不 存 
在 则 自动 创建 该 namespace， 推 荐 使 用 NamespaceLifecycle。 


--admission-control="AlwaysAdmit” NamespaceLifecycle: 如 果 尝 试 在 一 个 不 存在 的 namespace 中 创建 资源 对 象 ， 
则 该 创建 请 求 将 被 拒绝 。 当 删除 一 个 namespace 了 时， 系统 将 会 得 除 该 namespace 
中 的 所 有 对 象 ， 包 括 Pod. Service 等 。 
如 果 启 用 多 种 准 入 选项 ， 则 建议 加 载 的 顺序 是 : 
—admission-control=Namespacel ifecycle.LimitRanger,SecurityContextDeny,ServiceA 
ccount.ResourceQuota 
~-advertise-address=<nil> 用 于 广播 给 集群 的 所 有 成 员 自 己 的 下 地 址 ,不 指定 该 地 址 将 使 用 “一 bind-address” 
定义 的 下 地址 
~allow-pnvileged=false 如 果 设 置 为 tue， 则 Kubemetes 将 允许 在 Pod 中 运行 拥有 系统 特权 的 容器 应 用 ， 
与 docker run --privileged 的 功效 相同 


集群 中 运行 的 API Server 数量 


—authentication-token-webhook-cache- | 将 webhook token authenticator 返回 的 响应 保存 在 绥 存 内 的 时 间 ， 默 认为 两 分 钟 
tti-2m0s 
Webhook 相关 的 配置 文件 ， 将 用 于 token authentication 


--authorization-mode="AlwaysAllow” 到 API Server 的 安全 访问 的 认证 模式 列表 ， 以 逗号 分 陋 ， 可 选 值 包括 : 
AlwaysAllow. AlwaysDeny, ABAC, Webhook. RBAC 


i 4. guthorization-mode 设置 为 RBAC 时 使 用 的 超级 用 户 名 ， 使 用 该 用 户 名 可 以 不 
—authorization-webhook-cache-authonzed | 将 webhook authorizer 返回 的 “已 授权 ”响应 保存 在 缓存 内 的 时 间 , 默认 为 5 分 钟 。 

将 webhook authorizer 返回 的 “未 授权 ”响应 保存 在 缓存 内 的 时 间 ， 默 认为 30 秒 
ized-ttl=30s 


Kubemetes API Server 在 本 地 址 的 6443 端口 开启 安全 的 HTTPS 服务 ， 默 认为 000.0 


--cert-dir="/var/run/kubemetes TLS FBAR, Mi Awar'rumkubernetes, Pi T --tls-cert-file 和 


CORS ( 跨 域 资源 共享 ) 设置 允许 访问 的 源 域 列表 ， 用 豆 导 分 隔 ， 并 可 使 用 正则 
表达 式 匹 配子 网 。 如 果 不 指定 ， 则 表示 不 启用 CORS 
-deserialization-cache-size=50000 


-— 
当 -authorizationmode 设置 为 webhook 时 使 用 的 授权 配置 文件 
设置 该 文件 用 于 通过 HTTP 基本 认证 的 方式 访问 API Server 的 安全 端口 


参数 名 和 取信 示例 


设置 为 tue 表示 启用 垃圾 回收 器 .必须 与 kube-controller-manager 的 该 参数 设置 为 
相同 的 值 


设置 为 rue 表示 启用 swagger wi 网 页 ， 可 通过 API Server 的 URL/swagger-ui 访问 
ated keyfle-™” 
~eted-prefix="registry” 
设置 为 rue 表示 启用 quorum read 机 制 
DLS ST MEA eted 服务 URL FUR. eted ARSE http://ap-port 格式 表示 
KRM ecd MARRE. DUESH. HARRA: group/resource 
Sservers, St? servers 格式 为 http://ip:port， 以 分 号 分 隔 


Kubemetes API Server 中 各 种 事件 (通常 用 于 审计 和 追踪 ) 在 系统 中 保存 的 时 间 ， 
默认 为 1 小 时 


用 于 生成 该 Master 的 对 外 URL 地 址 ， 例 如 用 于 swagger api 文档 中 的 URL 地 址 。 
--insecure-bind-address=127.0.0.1 绑 定 的 不 安全 卫 地 址 , 5j-—-insecure-port 共同 使 用 ,默认 为 localhost。 设 置 为 0.0.0.0 
表示 使 用 全 部 网 络 接口 


提供 非 安全 认证 访问 的 监 昕 端口 ， 默 认为 8080。 应 在 防火 墙 中 进行 配置 ， 以 使 得 
外 部 客户 端 不 可 以 通过 非 安全 端口 访问 API Server 

设置 InitialResourees 使 用 的 数据 源 ， 可 配置 项 包括 influxdd. gem 

InitialResources 所 需 指标 保存 在 infiuxdb 中 的 数据 库 名 称 ， 默 认为 k8s 


—ir-hawkular-"" 
—irinfluxdb-host-"localhost:8080/api'v | InitialResources 记 雷 指标 所 在 influxdb 的 URL ht, MUA localhost:$080/ 
l/proxy/namespaces/kube-system/servic api'vl/proxy/namespaces/kube-system/services/monitoring-influxdb:api 


es/monitonng-influxdb:api" 


连接 influxdb 数据 库 的 密码 
Initial Resources 进行 资源 估算 时 的 采样 百分比 ， 实 验 用 


连接 influxdb 数据 库 的 用 户 名 


用 于 CA 授权 的 cert 文件 路 和 


指定 kubelet 是 否 使 用 HTTPS 连接 
kubelet 执行 操作 的 超时 时 间 
--kubemetes-service-node-port=0 WH Master 服务 是 否 使 用 NodePort 模式 ， 如 果 设 置 ， 则 Master 服务 将 映射 到 物 
理 机 的 端口 号 ， 设 置 为 0 表示 以 ClusterIP 的 形式 启动 Master 服务 


| — S$H&RBATM | 说 m» — | 

-long-running-request-regexp-"(/^)((w | 以 正则 表达 式 配 置 哪些 需要 长 时 间 执 行 的 请 求 不 会 被 系统 进行 超时 处 理 

atchiproxy)(/|$))(logs?|portforwardjexec|a 

ttach)/?$)" 

--max-connection-bytes-per-sec=0 设置 为 非 0 的 值 表 示 限 制 每 个 客户 端 连接 的 带宽 为 xx 字 节 / 秒 ， 目 前 仅 用 于 需要 
长 时 间 执 行 的 请 求 

--max-requests-inflight=400 同时 处 理 的 最 大 请 求 数量 ， 默 认为 400， 超 过 该 数量 的 请 求 将 被 拒绝 。 设 置 为 0 
表示 无 限制 


最 小 请 求 处 理 超时 时 间 ， 单 位 为 秒 ， 默 认为 1800 秒 ， 目 前 仅 用 于 watch request 
handler， 其 将 会 在 该 时 间 值 上 加 一 个 随机 时 间作 为 请 求 的 超时 时 间 

Er 该 文件 内 设置 鉴 权 机 构 ，OpenID Server 的 证 书 将 被 其 中 一 个 机 构 进行 验证 。 如 果 

i | 不 设置 ， 则 将 使 用 主机 的 root CA 证 书 


file="" 
OpenID Connect (fj 38 ID, «€ oide-issuer-url 设置 时 必须 设置 
定制 的 OpenID Connect 用 户 组 声明 的 设置 ， 以 字符 吊 数组 的 形式 表示 ， 实 验 用 


—oidc-issuer-url= OpenID 发 行者 的 URL 地 址 ， 仅 支持 HTTPS scheme， 用 于 验证 OIDC ISON Web 
Token (JWT) 


~-oide-username-claim="sub" OpenID claim 的 用 户 名 ， 默 认为 “sub”， 实 验 用 


打开 性 能 分 析 ， 可 以 通过 <host>:<port>/debug/pprof 地 址 查看 程序 栈 、 线 程 等 系 
统 信息 


--repair-malformed-updates[=true] 设置 为 true 表示 服务 器 将 尽 可 能 修复 无 效 或 格式 错误 的 update request， 以 通过 正 
确 性 校 验 ， 例 如 在 一 个 update request 中 将 一 个 已 存在 的 UD FRR AZ 


--runtime-config= 一 组 key=value 用 于 运行 时 的 配置 信息 。 apis/<groupVersion=/<resource> 可 用 于 打 
开 或 关闭 对 某 个 API 版 本 的 支持 。api/all 和 apilegacy 特别 用 于 支持 所 有 版 本 的 

EMEN 
—service-account-key-file-"" 包含 PEM-encoded x509 RSA 公 钥 和 私 钥 的 文件 路 径 ， 用 于 验证 Service Account 


的 token。 不 指定 则 使 用 --tls-private-key-file 指定 的 文件 


设置 为 tme 时， 系统 会 到 eted 验证 ServiceAccount token 是 否 存在 


--service-cluster-ip-range==nil> Service 的 Cluster IP (H40 IP) 池 ， 例 如 169.169.0.0/16, 3&4 IP 地 址 池 不 能 与 物 
理 机 所 在 的 网 络 重合 

--service-node-port-range= Service 的 NodePort 能 使 用 的 主机 端口 号 范围 , RUA 30000 —32767. 包括 30000 
和 32767 


如 果 指定 ， 则 通过 SSH 使 用 指定 的 秘 钥 文 件 对 Node 进行 访问 
如 果 指定 ， 则 通过 SSH 使 用 指定 的 用 户 名 对 Node 进行 访问 
设置 持久 化 存储 类 型 ， 可 选项 为 etcd2 (默认 )、eted3 


--storage-media-type="applicationjson” | 持久 化 存储 中 的 保存 格式 ， 默 认为 applicationijson。 某 些 资 源 类 型 只 能 使 用 
application/json 格式 进行 保存 ， 将 忽 络 这 个 参数 的 设置 


续 表 
—storage-versions-"apps/vlalphalauthe | 持久 化 存储 的 资源 版 本 号 ， 以 分 组 形式 标记 ， 例 

ntication k8s.io/vlbetal.authorization k8 | 如 “groupl/versionl1.group2/version2....™ 

s.io/v1betal autoscaling/v1,batch/v1.co 
mponentconfig/vlalphal .extensions/v1b 


etal.policy/vlalphal.rbac authorization. 
k8s.io/vlalphal.vl" 


—tls-cert-file- 7 包含 x509 证 书 的 文件 路 径 ， 用 于 HTTPS 认证 


--tls-private-key-file="”" 包含 x509 与 tls-cert-file 对 应 的 私 钥 文件 路 径 

--token-auth-file="" 用 于 访问 API Server 安全 端口 的 token 认证 文件 路 径 

—watch-cache-sizes-[] 设置 各 资源 对 象 watch 缓存 大 小 的 列表 ， 以 逗号 分 隔 ， 每 个 资源 对 象 的 设置 格式 
为 resource#size, “4 watch-cache 设置 为 true 时 生效 


3.kube-controller-manager/H 2/2: 2 
对 kube-controller-manager 启 动 参数 的 详细 说 明 如 表 2.5 所 示 。 


322.5 ”对 kube-controller-manager 启 动 参数 的 详细 说 明 


参数 名 和 取 值 示例 说 阴 
--address=0.0.0.0 监听 的 主机 IP 地 址 ， 默 认为 0.0.0.0 表示 使 用 全 部 网 络 接口 
--allocate-node-cidrs=false 设置 为 tue 表示 使 用 云 服务 商 为 Pod 分 配 的 CIDRs， 仅 用 于 公有 云 
--cloud-config-"" 云 服 务 商 的 配置 文件 路 径 ， 仅 用 于 公有 云 
--cloud-provider-"" 云 服务 商 的 名 称 ， 仅 用 于 公有 云 
--cluster-cidr=<nil> 集群 中 Pod 的 可 用 CIDR 范围 
--cluster-name="kubernetes” 集群 的 名 称 ， 默 认为 kubernetes 
--concurrent-deployment-synes=5 设置 允许 的 并 发 同步 deployment 对 象 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 
消耗 更 多 的 CPU 和 网 络 资源 
--concurrent-endpoint-synes=5 设置 并 发 执行 Endpoint 同步 操作 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 消耗 
更 多 的 CPU 和 网 络 资源 
--concurrent-rc-syncs-5 并 发 执行 RC 同步 操作 的 协 程 数 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 消耗 更 多 的 
CPU 和 网 络 资源 
--concurrent-namespace-syncs-2 设置 允许 的 并 发 同步 namespace 对 象 的 数量 ， 值 越 大 表示 同步 操作 越 快 ， 但 将 会 
消耗 更 多 的 CPU 和 网 络 资源 
--concurrent-rc-syncs-5 设置 允许 的 并 发 同步 replication controller 对 象 的 数量 , 值 越 大 表示 同步 操作 越 快 ， 
但 将 会 消耗 更 多 的 CPU 和 网 络 资源 
--concurrent-replicaset-synes=5 设置 允许 的 并 发 同步 replica set 对 象 的 数量 , 值 越 大 表示 同步 操作 越 快 , 但 将 会 消 
耗 更 多 的 CPU 和 网 络 资源 


--concurrent-resource-quota-synes=5 设置 允许 的 并 发 同步 resource quota 对 象 的 数量 , 值 越 大 表示 更 快 地 进行 同步 操作 ， 

但 将 会 消耗 更 多 的 CPU 和 网 络 资 源 
设置 为 true 表示 使 用 allocate-node-cidrs 进行 CIDR: 的 分 配 ， 仅 用 于 公有 去 

--daemonset-lookup-cache-size=1024 DaemonSet 的 查询 绥 存 大 小 ， 默 认为 1024。 值 越 大 表示 DaemonSet 响应 越 快 ， 内 
存 消耗 也 越 大 

--deleting-pods-burst=10 如 果 一 个 Node 节点 失败 ， 则 会 批量 剔除 在 上 而 运行 的 Pod 实例 的 信息 ， 此 值 定义 
TRAE Pod 的 数量 ， 与 deleting-pods-qps 一 起 作为 调度 中 的 限 流 因子 

--enable-garbage-collector{[=false] 设置 为 true 表示 启用 垃圾 回收 机 制 , 必须 与 kube-apiserver 的 该 参数 设置 为 相同 的 值 

--enable-hostpath-provisioner[=false] 设置 为 true 表示 启用 hostPath PV provisioning 机 制 , 仅 用 于 测试 ,不 可 用 于 多 Node 
的 集群 环境 

-volume-phigin-di="‘usr/libexecku | 设置 flex volume 插件 应 搜索 其 他 第 三 方 volume 插件 的 全 路 径 
bemetes/kubelet-pluzins/volume/exec!” 


--horizontal-pod-autoscaler-syne-penod | Pod 自动 扩容 器 的 Pod 数量 的 同步 时 间 间 隔 ， 默 认为 30 秒 
=30s 


发 送 到 API Server 的 每 秒 的 请 求 数量 ， 默 认为 30 


—kube-api-content-type-"application'vn | 发 送 到 API Server 的 请 求 内 容 类 型 
dkubemetes protobuf 
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kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 信息 
设置 为 ue 表示 进行 leader 选举 ， 用 于 多 个 Master 组 件 的 高 可 用 部 团 


leader 选举 过 程 中 非 leader 等 待 选举 的 时 间 间 隔 , 默认 为 15 秒 , 当 leader-elect-true 


leader 选举 过 程 中 在 停止 leading 角色 之 前 再 次 renew 的 时 间 间 隔 ， 应 小 于 或 等 于 
leader-elect-lease-duration， 默 认为 10 秒 ， 当 leader-elect=true 时 生效 
~-leader-elect-retry-period=2s leader 选举 过 程 中 在 获取 leader 角色 和 renew 之 间 的 等 待 时 间 ， 默 认为 两 秒 ， 当 
leader-elect=true 时 生效 
~-min-resyne-period=12h0m0s 最 小 重新 闻 步 的 时 间 和 间隔 ， 实 际 重新 同步 的 时 间 为 MinResyncPeriod (默认 为 12 
小 时 ) 到 2xMinResyncPeriod (默认 24 小 时 ) 之 间 的 一 个 随机 数 


--node-monitor-grace-peniod=40s 监控 Node 状态 的 时 间 间 隔 , 默认 为 40 秒 , 超过 该 设置 时 间 后 ，controller-manager 
会 把 Node 标记 为 不 可 用 状态 。 此 值 的 设置 有 如 下 要 求 : 
它 应 该 被 设置 为 kubelet 汇报 的 Node 状态 时 间 间 隔 (参数 一 node-status-update- 
frequency=10s) 的 入 售 ，N 为 kubelet 状态 汇报 的 重 试 次 数 


同步 NodeStatus 的 时 间 间 陋 ， 默 认为 5 秒 


Node 启动 的 最 大 允许 时 间 ， 超 过 此 时 间 无 响应 则 会 标记 Node 为 不 可 用 状态 OA 
动 失败 )， 默 认为 1 分钟 
--node-sync-period=10s Node 信息 发 生变 化 时 【例如 新 Node 加 入 集群 )controller-manager 同步 各 Node 
在 发 现 一 个 Node 失效 以 后 , 延迟 一 段 时 间 , 在 超过 这 个 参数 指定 的 时 间 后 , 删除 

Jt Node 上 的 Pod， 黑 认为 5 分 名 


controller manager WIS WUBI, BRU 10252 


打开 性 能 分 析 ， 可 以 通过 <host=:<=port=/aebugipprog 地 直 查 看 程序 栈 、 线 程 等 系统 
默认 为 30 秒 
使 用 hostPath recycler 的 Pod 的 最 小 ActiveDeadlineSeconds 秒 数 ， 默 认为 60 秒 。 


0 
—pv-recycler-pod-template-filepath-host | 使 用 hostPath recycler 的 Pod 的 模板 文件 全 路 径 ， 仅 用 于 实验 
path: 

0 


=6| 
I recycle I Pod IWR ActiveDezdlineSeconds BML, RUA 300 B 


使 用 nf recycler 的 Pod 的 模板 文件 全 路 多 
—pv-recycler-timeout-increment-hostpath | 使 用 hostPath scrubber 的 Pod 每 增加 1Gi 空间 在 ActiveDeadlineSeconds 上 增加 的 
za Hif], RUA 30 秒 。 实 验 用 


—replicaset-lookup-cache-:ize-4096 WW replica sets 查询 缓存 的 大 小 ， 默 认为 4096， 值 越 大 表示 查询 操作 越 快 ， 但 将 
设置 replication controller 查询 级 存 的 大 小 ， 默 认为 4096， 值 越 大 表示 查询 操作 越 
=4096 快 ， 但 将 会 消耗 更 多 的 内 存 


同步 PV 和 PVC (容器 声明 的 PV》 的 时 间 向 隔 


resource quota 使 用 信息 同步 的 时 间 和 间隔， 默认 为 5 分 名 
—service-account-private-key-file-"" Hi T £i Service Account token 签名 的 PEM-encoded RSA 私 钥 文 件 路 径 


--terminated-pod-ge-threshold=12500 设置 可 保存 的 终止 Pod 的 数量 ， 超 过 该 数量 ， 垃 圾 回收 器 将 开始 进行 删除 操作 。 
设置 为 不 大 于 0 的 值 表示 不 启用 该 功能 


4.kube-scheduler 启 动 参数 
对 kube-scheduler 启 动 参数 的 详细 说 明 如 表 2.6 所 示 。 


表 2.6 ”对 kube-scheduler 启 动 参数 的 详细 说 明 


参数 名 和 取 值 示例 说 A 
--address=0.0.0.0 监听 的 主机 下 地址， 默认 为 0.0.0.0 表示 使 用 全 部 网 络 接口 
—algorithm-provider-"DefaultProvider | 设置 调度 算法 ， 默 认为 DefaultProvider 
--failure-domains="kubemetes.io/hostnam | 表示 Pod 调度 时 的 亲和力 参数 。 在 调度 Pod M, ARP Pod 有 相同 的 亲和力 参 
e.failure-domain.beta kubemetes.io/zonef | 数 ， 那 么 这 两 个 Pod 会 被 调度 到 相同 的 Node b: 如 果 两 个 Pod 有 不 同 的 亲和力 参 
ailure-domain.beta kubernetesio/region" | 数 ， 那 么 这 两 个 Pod 不 会 被 调度 到 相同 的 Node 上 


--hard-pod-affinity-symmetric-weight=1 | 表示 Pod 调度 规则 亲和力 的 权重 值 , 取 值 范围 为 0 一 100. RequiredDuringScheduling 
亲 和 性 是 非 对 称 的 ， 但 对 每 一 个 RequiredDuringScheduling 亲 和 性 都 存在 一 个 对 应 的 隐 
式 PreferedDuringScheduling 亲 和 性 规则 。 该 设置 表示 隐 式 PreferedDuringScheduling 
亲 和 性 规则 的 权重 值 ， 默 认为 1 


发 送 到 API Server 的 每 秒 请 求 数量 ， 默 认为 100 


--kube-api-content-type="application/vnd. | 发 送 到 API Server 的 请 求 内 容 类 型 
kubemetes protobuf” 


与 ApL Server 通信 的 QPS 值 ， 默 认为 50 


kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 的 地 址 信息 及 必要 的 认证 信息 
设置 为 true 表示 进行 leader 选举 ， 用 于 多 个 Master 组 件 的 高 可 用 部 署 
leader 选举 过 程 中 非 leader 等 待 选举 的 时 间 则 隔 , 默认 为 15 秒 , 当 leader-elect=true 
时 生效 
leader 选举 过 程 中 在 停止 leading 角色 之 前 再 次 renew 的 时 间 间 陋 ， 应 小 于 或 等 于 
leader-elect-lease-duration， 默 认为 10 秒 ， 当 leader-elect=true 时 生效 


调度 策略 (scheduler policy) 配置 文件 的 路 径 
scheduler 监听 的 主机 端口 号 ， 默 认为 10251 
打开 性 能 分 析 ， 可 以 通过 <host>:<port=/debug/pprof/ 地 址 查看 栈 、 线 程 等 系统 运行 
信息 

-scheduler-name-"default-scheduler" 调度 器 名 称 ， 用 于 选择 哪些 Pod 将 被 该 调度 器 进行 处 理 ， 选 择 的 依据 是 Pod 的 
annotation 设置 ， 包 含 key='scheduler.alpha kubernetes.io/name 的 annotation 


5.kubelet 启 动 参数 
对 kubelet 启 动 参数 的 详细 说 明 如 表 2.7 所 示 。 
表 2.7 ”对 kubelet 启 动 参 数 的 详细 说 明 


SUE EELIP HOHE, BVH 0.0.0.0 表示 使 用 全 部 网 络 接口 
~allow-privileged{=false] 
API Server 地 址 列表 ， 以 :port 格式 表示 ， 以 逗号 分 隔 


以 逗号 分 隔 的 文件 列表 ， 使 用 第 1 个 存在 book-id 的 文件 
boot 1d" 


--cadvisor-port=4194 本 地 cAdvisor USD S. MUAH 4194 


cilio TLS 证 书 所 在 的 目录 ， 默 认为 /varirun/kubemetes。 如 果 设置 了 -ds-cert-file 和 
为 pods 设置 的 root cgroup， 如 果 不 设置 ， 则 将 使 用 容器 运行 时 的 默认 设置 
随机 产生 客户 端 错误 的 概率 ， 仅 用 于 测试 ， 默 认为 0， 即 不 产生 
云 服务 商 的 名 称 ， 默 认 将 自动 检测 ， 设 置 为 空 表示 无 云 服务 前 

i 

-ch -domain-^ 

—configa"" 
~configure-cbr0[=false] 


x 
集群 内 DNS BUSH RIAL 


--container-runtime="docker" 容器 类 型 ， 目 前 支持 Docker, rkt. BRU docker 
将 kubelet 运行 在 容器 中 ， 仅 供 测试 使 用 ， 默 认为 alse 


--container-hints="/ete/cadvisor/container | 容器 hints 文件 所 在 的 全 路 径 
_hints json’ 


设置 为 tue 表示 启用 CPU CFS quota， 用 于 设置 容器 的 CPU 限制 
Docker 容器 需要 使 用 的 环境 变量 key AR, MESAM 

MA Docker 容器 中 执行 命令 的 方式 ， 支 持 native、nsenter， 默 认为 native 
Docker 要 目录 的 全 路 径 ， 不 再 使 用 ， 将 通过 docker info 获取 该 信息 


--enable-controller-attach-detach[=true] 设置 为 hue 表示 启用 Attach/Detach Controller 进行 调度 到 该 Node 的 volume 的 
attach 与 detach 操作 ， 同 时 禁用 kubelet 执行 attach、detach 的 操作 


设置 为 rue 表示 启用 采集 自 定义 性 能 指标 


设置 为 true 表示 提供 远程 访问 本 节点 容器 的 日 志 、 进 入 容器 执行 命令 等 相关 Rest 
服务 


设置 为 true 表示 启用 CPU 负载 的 reader 


—enable-server[-true] 启动 kubelet 上 的 http rest server, 此 server 提供 了 获取 本 节点 上 运行 的 Pod 列表 、 
Pod 状态 和 其 他 管理 监控 相关 的 Rest 接口 


设置 为 tue, KAUR Docker 容器 的 统计 信息 而 不 再 报告 其 他 统计 信息 


-docker-endpoint- Docker 服务 的 Endpoint ht, BRUA unix-///var/run/docker.sock 
"unix:///var/run/docker sock 


参数 名 和 取信 示例 
临时 允许 的 Event 记录 突 发 的 最 大 数量 ， 默 认为 10， 当 event-qps=0 时 生效 
设置 大 于 0 的 值 表示 限制 每 秘 能 创建 出 的 Event 数量 ， 设 置 为 0 表示 不 限制 


保存 Event 的 最 大 时 间 。 按 事件 类 型 以 key=value 的 格式 表示 ， 以 逗号 分 陋 ， 事 
件 类 型 包括 creation. oom 等 ，“default” 表示 所 有 事件 的 类 型 
—event-storage-event-limit="default=0" 保存 Event 的 最 大 数量 。 按 事件 类 型 以 key=value HK. LUBE AM. MH 
终止 Pod 操作 给 Pod 自行 停止 预 留 的 对 间 ， 单 位 为 秘 。 MAPAN, HEAR Pod 
Eviction 澡 作 。 默 认 值 为 0， 设置 为 负数 表示 使 用 Pod 中 指定 的 值 


复发 Pod Eviction 操作 的 一 组 软 门 限 设 置 ， 例 如 可 用 肉 存 <1.5Gi, 与 grace-period 


—eviction-soft="" 


一 起 生效 ， 当 Pod jm NAT fe] it grace-period AMET MUR 


4 8 Pod Eviction 操作 的 一 组 软 门限 等 待 时 间 设 置 , 04/0] memory available=1m30s 


设置 为 rue 表示 当 有 文件 锁 存 在 时 kubelet 也 可 以 退出 
实验 性 功能 ， 用 于 kubelet 启动 时 自动 支持 aannel MAR, BUG false 
本 节点 上 NVIDIA GPU 的 数量 ， 目 前 仅 支持 0 GEL. RUHO 
~file-check-frequency=20s 在 File Source 作为 Pod 源 的 情况 下 , kubelet 定期 重新 窒 查 文件 变化 的 时 间 他 隔 ， 
文件 发 生变 化 后 ，lkubelet 重新 加 载 更 新 的 文件 内 容 
H FAIA Y G Service Account iit RET EBL ISON key 
-hairpin-mode="promiscuous-bridge” — | if H hairpin Hist, C7: kubelet 设置 hairpin NAT 的 方式 .该 模式 允许 后 端 Eadpoint 
在 访问 其 本 身 Service MEAE PY loadbalance 回 自身 、 可 选项 包括 promiscuous- 
bridge, hairpin-veth 和 none 
--healthz-bind-address=127.0.0.1 healthz 84H 97 89 IP 地 址 ， 默 认为 127.0.0.1, BRA 0.0.0.0 表示 监 昕 全 部 卫 
地 址 
~-host-ipe-sources="*" kubelet Jti Pod 使 用 宿主 机 ipe namespace M/Z, MESA, BiH “*" 
kubelet 允许 Pod 使 用 宿主 机 network HHR, LOTSA, RUA“ 
kubelet 允许 Pod 使 用 宿主 机 pid namespace 的 列表 ， 以 到 号 分 隔 ， 默 认为 6" 
对 容器 做 housekeeping 操作 的 时 间 间 隔 ， 默 认为 10 和 


--http-check-frequency=20s HTTP URL Source 作为 Pod 源 的 销 况 下 ，kubeiet 定期 检查 URL 返回 的 内 容 是 否 
发 生变 化 的 时 间 周 期 ， 和 作用 同 file-check-frequency 5 $t 


镜像 垃圾 回收 上 限 ， 磁 级 使 用 空间 达到 该 百分比 时 ， 和 镜像 垃圾 回收 将 持续 工作 
镜像 垃圾 回收 下 限 ， 磁盘 使 用 空间 在 达到 该 百分比 之 葡 , BR EUR 
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续 表 
参数 名 和 取信 示例 Ss UN ae 


-kubemetes.protobuf” 

--kube-reserved= kubernetes 系统 预 留 的 资源 配置 , 以 一 组 ResourceName=ResourceQuantity 格式 表 
示 ， 例 如 cpu=200m.memory=150G。 目前 仅 支 持 CPU 和 内 在 的 设置 ， 详 见 http:// 
releases k8s_io(HEAD/docs/user-guide/compute-resources:md, UHF 

| -od-Se-" | kubelet (EFH lock tfe. Alpha tii | 

设置 为 true 表示 将 cAdvisor 容器 的 使 用 情况 进行 日 志 记录 

--low-diskspace-threshold-mb=256 本 Node 最 低 磁 盘 可 用 空间 ， 单 位 MB. SBS MRP IRM, kubelet 将 拒绝 
创建 新 的 Pod， 默 认 值 为 256MB 

--machine-id-file="/etc’machine-id,/varli | 用 于 查找 machine-id 的 文件 列表 ， 使 用 找到 的 第 1 MH. BVM ete/machine-id, 


b/dbus/machine-id" /var/lib/dbus/machine-id 文件 中 去 查找 
—manifest-url-" 23 HTTP URL Source 源 类 型 时 , kubelet 用 来 获 到 Pod 定义 的 URL 地 址 , 此 URL 
返回 一 组 Pod 定义 


Master 服务 的 命名 空间 ， 默 认为 default 
kubelet 打开 的 最 大 文件 数量 ， 默 认为 1000 000 
kubelet 能 运行 的 最 大 Pod 数量 ， 默 认为 110 个 Pod 


--maximum-dead-containers=240 (EX: Node (RMN CHPSIETERRSOT ROCHE. PMS SARA DU]. BT 
以 超过 该 上 限 以 后 ，kubelet 会 自动 清理 已 停止 的 容器 以 释放 磁盘 室 间 ， 默 认为 240 


以 Pod 为 单位 可 以 保留 的 已 停止 的 属于 同一 Pod 的 ) 容器 集 的 最 大 数量 


访问 menifest URL 地 址 时 使 用 的 HTTP 头 信息 ， 以 keyvalue 格式 表示 


E 

--minimum-container-ttl-duration-lm0s 已 停止 的 容器 在 被 清理 之 前 的 最 小 存活 时 间 ， 例 如 300ms、10s 或 2h45m， 超 过 
此 存活 时 间 的 容器 将 被 标记 为 可 被 GC 清理 ， 默 认 值 为 1 分 钟 

--minimum-image-tt]-duration=2m0s 不 再 使 用 的 镜像 在 被 清理 之 前 的 最 小 存活 时 间 ， 例 如 300ms. 10s 或 2h45m， 超 
过 此 存活 时 间 的 镜像 被 标记 为 可 被 GC 清理 ， 默 认 值 为 两 分 钟 


自 定义 的 网 络 插件 的 名 字 , Pod 的 生命 周期 中 相关 的 一 些 事件 会 调用 此 网 络 插件 


--network-plugzin- 


进行 处 理 ， 为 Alpha 测试 版 功能 
--network-plugin-di="/usr/libexeckkuber | 扫描 网 络 插件 的 目录 ， 为 Alpha 测试 版 功能 


netes/kubelet-plugins/net/exec/" 
GE oe HPN 
--node-labels= kubelet 注册 本 Node 3212 W (l'] Labels, label 以 key=value 的 格式 表示 ， 多 个 label 


以 逗号 分 隔 ， 为 Alpha 测试 版 功能 


--node-status-update-frequency=10s kubelet [s] Master 汇报 Node 状态 的 时 间 间 隔 ， 默 认 值 为 10 Eb. 45 controller- 
manager 的 一 node-monitor-grace-period $i [s] de f Hj 


kubelet 向 该 他 BEŽ ^H] IP 地 址 发 送 的 流量 将 使 用 IP Masquerade 技术 


续 表 
kubelet 进程 的 oom score adj 参数 值 ， 有 效 范围 为 [-1000, 1000] 


~-pod-cidr="" 用 于 给 Pod 分 配 IP 地 址 的 CIDR 地 址 池 ， 仅 在 单机 模式 中 使 用 。 在 一 个 集群 中 ， 
kubelet 会 从 API Server 中 获取 CIDR 设置 


--pod-infra-container-image="gcr-10/ 用 于 Pod 内 网 络 命名 空间 共享 的 基础 pause 镜像 
containers/pause-amd64-3.0™ 


google 
--pods-per-core=0 该 kubelet 上 每 个 core 可 运行 的 Pod 数量 。 最 大 值 将 被 max-pods SAES. R 
认 值 为 0 表示 不 做 限制 
a 


kubelet 服务 监听 的 “只 读 ” 端 口号， 默认 为 10255， 设 置 为 0 表示 不 启用 
设置 为 tue RARE panies WM, CUE MR 


--reconcile-cidr[=true] 根据 API Server 指定 的 CIDR Wd Node 的 CIDR 地 址 ， 如 果 register-node 或 
configure-cbrÜ 设置 为 名 lse， 则 表示 不 启用 。 默 认 值 为 rue 


将 本 Node 注册 到 API Server, UHH tme 


—register-schedulable[-true] 将 本 Node 状态 标记 为 schedulable, 12 HH false 表示 通知 Master 本 Node 不 可 进 
TAR. RUA tue 


最 多 同时 拉 取 镜像 的 数量 ， 默 认 值 为 10 


-registry-qps-5 在 Pod 创建 过 程 中 容器 的 镜像 可 能 需要 从 Registry PRIR, 由 于 拉 取 镜像 的 过 程 中 
会 消耗 大 量 带 帘 ， 因此 可 能 需要 限 速 ,此 参数 与 registy-bwst 一 起 用 来 很 制 每 秒 拉 
取 多 少 个 镜像 ， 默 认 不 限 速 ， 如 果 设 置 为 5， 则 表示 平均 每 秒 允 许 拉 取 5 个 镜像 


命名 服务 配置 文件 ， 用 于 容器 内 应 用 的 DNS MUS. BRU /ete/resolv.conf 
rit APT 服务 的 URL 地 址 ，--container-runtime="tkt 时 生效 


xke 二 进 制 文件 的 路 径 , 不 指定 的 话 从 环境 变量 SPATH 中 查找 , --container-runtime 
—rkt IE ^ 


kubelet 运行 根 目录 ， 将 保持 Pod 和 volume 的 相关 文件 ， 默 认为 /varlib/kubelet. 


设置 为 tue 表示 创建 完 Pod 之 后 立即 退出 kubelet 进程 ， 与 -apiservers 和 
--enable-server $i H JF 
ili ain teach Quas 除了 长 时 间 运 行 的 request, 对 其 他 request 的 超时 时 间 设置 , 8145 pull logs. exec. 


attach 等 操作 。 当 超时 时 间 到 达 时 ， 请 求 会 被 杀 掉 ， 抛 出 一 个 错误 并 会 重 试 。 默 
认 值 为 两 分 钟 


--seccomp-profile-root="/var/lib/kubelet/s | seccomp 配置 文件 目录 ， 默 认为 /var/lib/kubelet/seccomp 
eccomp™ 


HFEA pull HAR. MIL Docker (EF <1.9 版 本 或 使 用 Aufs storage backend 时 
设置 为 hue， 详 见 issue #10959 


将 缓存 数据 写 入 后 端 存 储 的 时 间 间 三， 默认 为 1 分 钟 


参数 名 和 取 值 示例 mom 
后 端 存储 的 数据 库 连 接 URL 地 址 ， 默 认为 localhost8086 
—storage-driver-password-" root" 后 端 存储 的 数据 库 密码 ， 默 认为 root 
—storage-driver-secure[-false] 后 端 存储 的 数据 库 是 否 用 安全 连接 ， 默 认为 false 
后 端 存储 的 数据 库 用 户 名 ， 默 认为 root 
—streaming-connection-idle-timeout= 在 容器 中 执行 命令 或 者 进行 端口 转发 的 过 程 中 会 产生 输入 、 输 出 流 , 这 个 参数 用 
4h0m0s 来 控制 连接 空闲 超时 而 关闭 的 时 间 ， 如 果 设 置 为 “Sm”*， 则 表示 连接 超过 5 分 钟 


没有 和 输入 、 输 出 的 情况 下 就 被 认为 是 空闲 的 ， 而 会 被 自动 关闭 。 默 认为 4 小 时 


同步 运行 中 容器 的 配置 的 频率 ， 默 认为 IAM 
—system-cgroups-"" kubelet 为 运行 非 kernel 进程 设置 的 cgroups 名 称 
—system-reserved- 系统 预 留 的 资源 配置 ， 以 一 组 ResourceName-ResourceQuantity 格式 表示 ， 例 如 
cpu=200m.memory=150G- 目 前 仅 支 持 CPU 和 内 存 的 设置 , 详 见 http://releases.k8s. 
io/HEAD/docs/user-guide/compute-resources.md, UHE 
包含 x509 55 ths-cert-file 对 应 的 私 钥 文件 路 径 
一 volume-plugin-dir="/usr/libexec/kubern | 搜索 第 三 方 volume 插件 的 目录 ， 为 Alpha 测试 版 功能 
etes/kubelet-plugins/volume/exec/" 
—volume-stats-agg-period=1m0s kubelet 计算 所 有 Pod 和 volume 的 磁盘 使 用 情况 聚合 值 的 时 间 间 隔 ， 默 认为 1 分 
钟 。 设 置 为 0 表示 不 启用 该 计算 功能 


6.kube-proxy 启 动 参 类 
kube-proxy 的 启动 参数 详细 说 明 见 表 2.8。 


表 2.8 ”kube-proxy 的 参数 表 


参数 名 和 取 值 示例 说 ĦA 
--bind-address=0.0.0.0 kube-proxy 绑 定 主机 的 IP 地 址 ， 默 认为 0.0.0.0 表示 绑 定 所 有 IP 地 址 
--cleanup-iptables[=false] 设置 为 true 表示 清除 iptables 规则 后 退出 
--cluster-cidr="" 集群 中 Pod 的 CIDR 地 址 范围 ， 用 于 桥接 集群 外 部 流量 到 内 部 。 用 于 公有 云 
环境 
--config-sync-period=15m0s 从 API Server 更 新 配置 的 时 间 间 隔 ， 默 认为 15 分 钟 ， 必 须 大 于 0 
--conntrack-max=0 跟踪 NAT 连接 的 最 大 数量 ， 默 认 值 为 0 表示 不 限制 
--conntrack-max-per-core=32768 跟踪 每 个 CPU core 的 NAT 连接 的 最 大 数量 ,默认 值 为 32768, 仅 当 conntrack- 
max 设置 为 0 时 生效 
--conntrack-tep-timeout-established=24h0m0s | 建立 TCP 连接 的 超时 时 间 ， 默 认为 24 小 时 ， 设 置 为 0 表示 无 限制 


参数 名 和 取 值 示例 


LEE: 


--healthz-bind-address=127.0.0.1 


healthz 服务 绑 定 主机 IP 地 址 ， 默 认为 127.0.0.1， 设 置 为 0.0.0.0 表示 使 用 所 
有 下 地 址 


--healthz-port=10249 


healthz 服务 监听 的 主机 端口 号 ， 默 认为 10249 


--hostname-override="" 


设置 本 Node 在 集群 中 的 主机 名 ， 不 设置 将 使 用 本 机 hostanme 


--iptables-masquerade-bit=14 


iptables masquerade 的 fwmark 位 设置 ， 有 效 范围 为 [0. 31] 


--iptables-sync-period=30s 


刷新 iptables 规则 的 时 间 间 隔 ， 例 如 Ss、lm、2h22m， 默 认为 30 秒 ， 必 须 大 
To 


--kube-api-burst=10 


发 送 到 API Server 的 每 秒 发 请 求 数 量 ， 默 认为 10 


--kube-api-content-type="application/vnd.kub 


emetes.protobuf" 


发 送 到 API Server 的 请 求 内 容 类 型 


--kube-api-qps=5 


tj API Server 通信 的 QPS fii, RUA 5 


--kubeconfig="" 


kubeconfig 配置 文件 路 径 ， 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 
信息 


--masquerade-all[=false] 


设置 为 true 表示 使 用 纯 iptables 代理 ， 所 有 网 络 包 都 将 做 SNAT 转换 


一 nn 


--master— 


API Server 的 地 址 


--oom-score-adj=-999 


kube-proxy 进程 的 oom score adj 参数 值 ， 有 效 范 围 为 [-1000.1000] 


--proxy-mode= 


代理 模式 ， 可 选项 为 iptables 或 userspace， 默 认为 iptables， 转 发 速度 更 快 。 当 
操作 系统 kemel MAER iptables 版 本 不 够 新 时 ， 将 自动 降级 为 userspace 模式 


--proxy-port-range= 


进行 Service 代理 的 本 地 端口 号 范围 ， 格 式 为 begin-end， 含 两 端 ， 未 指定 则 
采用 随机 选择 的 系统 可 用 的 端口 号 


--udp-timeout=250ms 


保持 空闲 UDP 连接 的 时 间 ， 例 如 250ms, 2s, 默认 值 为 250ms， 必 须 大 于 0， 


仅 当 proxy-mode=userspace 时 生效 


2.1.7 “Kubernetes 集 群 网 络 配置 方案 


在 多 个 Node 组 成 的 Kubernetes 集 群 内 ， 跨 主机 的 容器 间 网 络 互 通 
是 Kubernetes 集 群 能 够 正常 工作 的 前 提 条 件 。Kubernetes 本 号 并 不 会 对 
跨 主 机 容器 网 络 进行 设置 ， 这 需要 额外 的 工具 来 实现 。 除 了 谷歌 公有 
云 GCE 平 台 提 供 的 网 络 设置 ， 一 些 开 源 的 工具 包括 flannel ^ Open 
vSwitch、Weave、Calico 等 都 能 够 实现 跨 主 机 的 容器 间 网 络 互通 。 本 
节 将 对 常用 的 flannel、Open vSwitch 和 直接 路 由 三 种 配置 进行 详细 说 
BH o 


1.flannel (JE m) 


flanne FA 72 aA (Overlay Network) 模型 来 完成 对 网 络 的 打 
通 ， 本 节 对 flannel 的 安装 和 配置 进行 详细 说 明 。 


1) 安装 etcd 


由 于 fannel 使 用 etcd 作 为 数据 库 ， 所 以 需要 预先 安装 好 etcd， 详 见 
2.1.2 TU BJVLB 。 


2) 安装 flannel 


需要 在 每 台 Node 上 都 安装 flannel。flannel 软 件 的 下 载 地 址 为 
https://github.com/coreos/flannel/releases ° 将 下载 的 压缩 包 flannel- 
<version>-linux-amd64.tar.gz 解 压 ， 把 二 进 制 文件 flanneld 和 mk-docker- 


opts.sh 复 制 到 /usr/bin (或 其 他 PATH 环境 变量 中 的 目录 ) ， 即 可 完成 对 


flannel 的 安装 。 


3) 配置 flannel 


此 处 以 使 用 systemd 系 统 为 例 对 flanneld 服 务 进 行 配 置 。 编 辑 服 务 
配置 文件 /usr/lib/systemd/system/flanneld.service: 


[Unit] 
Description=flanneld overlay address etcd agent 
After=network.target 


Before=docker.service 


[Service] 
Type=notify 
EnvironmentFile=/etc/sysconfig/flanneld 


ExecStart=/usr/bin/flanneld -etcd- 


endpoints=${FLANNEL_ETCD} $FLANNEL_OPTIONS 


[Install] 
RequiredBy=docker.service 


WantedBy=multi-user.target 


编辑 配置 文件 /etc/sysconfig/flannel， 设 置 etcd 的 URL 地 址 : 


# flanneld configuration options 


# etcd url location. Point this to the server where 


etcd runs 


FLANNEL_ETCD="http://192.168.18.3:2379" 


# etcd config key. This is the configuration key that 
flannel queries 
# For address range assignment 


FLANNEL_ETCD_KEY="/coreos.com/network" 


在 启动 flanneld 服 务 之 前 ， 需 要 在 etcd 中 添加 一 条 网 络 配 置 记录 ， 
这 个 配置 将 用 于 flanneld 分 配给 每 个 Docker 的 虚拟 IP 地 址 段 。 


# etcdctl set /coreos.com/network/config '{ "Network": 


"10.1.0.0/16"}' 


4) 由 于 flannel 将 覆盖 docker0 网 桥 ， 所 以 如 果 Docker 服 务 已 启动， 
则 停止 Docker 服 务 。 


5) 启动 flanneld 服 务 : 


# systemctl restart flanneld 


6) 设置 docker0 网 桥 的 IP 地 址 : 


# mk-docker-opts.sh -i 
# source /run/flannel/subnet.env 


# ifconfig dockerO ${FLANNEL_SUBNET} 


完成 后 确认 网 络 接口 docker0 的 了 地 址 属于 flannel0 的 子 网 : 


# ip addr 
flannelo: 
flags-4305«UP, POINTOPOINT, RUNNING, NOARP, MULTICAST> mtu 
1472 
inet 10.1.10.0 netmask 255.255.0.0 
destination 10.1.10.0 
dockerO: flags=4163<UP, BROADCAST, RUNNING, MULTICAST> 
mtu 1500 
inet 10.1.10.1 netmask 255.255.255.0 


broadcast 10.1.10.255 


7) 重新 启动 Docker 服 务 : 


# systemctl restart docker 


Bll thse Be T flannel4& x PZB HJ xí o 


使 用 ping 命 令 验证 各 Node 上 docker0 之 间 的 相互 访问 。 例 如 在 
Node1 (docker0IP-10.1.10.1) 机 器 上 ping Node2 的 docker0 (docker0‘s 
IP-10.1.30.1) ， 通 过 flannel 能 够 成 功 连接 到 其 他 物理 机 的 Docker 网 
络 : 


$ ping 10.1.30.1 
PING10.1.30.1 (10.1.30.1) 56(84) bytes of data. 
64 bytes from 10.1.30.1: icmp_seq=1 ttl-62 time-1.15 
ms 


64 bytes from 10.1.30.1: icmp seq-2 ttl-62 time-1.16 


ms 


64 bytes from 10.1.30.1: icmp_seq=3 ttl-62 time=1.57 


ms 


我 们 也 可 以 在 etcd 中 查看 到 flannel 设 置 的 flannel0 地 址 与 物理 机 了 P 
地 址 的 对 应 规则 : 


# etcdctl 1s /coreos.com/network/subnets 
/coreos.com/network/subnets/10.1.10.0-24 
/coreos.com/network/subnets/10.1.20.0-24 


/coreos.com/network/subnets/10.1.30.0-24 


4 etcdctl get /coreos.com/network/subnets/10.1.10.0-24 
("PublicIP": "192.168.1.129"} 
# etcdctl get /coreos.com/network/subnets/10.1.20.0-24 
("PublicIP": "192.168.1.130"} 
4 etcdctl get /coreos.com/network/subnets/10.1.30.0-24 
("PublicIP": "192.168.1.131"} 


2.Open vSwitch (虚拟 交换 机 ) 


以 两 个 Node 为 例 ， 目 标 网 络 拓 扑 如 图 2.2 所 示 。 


Node1 Node2 


—— ai 一 一 NN — 
| 172 17 42 50 (172.17 4251] 
T 
L 1 | 
docker0 docker0 | 
172.17.42.1/24 L 172.17 43.1/24 | 
| 


GREE 
| 
| ethno > 1 i etho 
| | 192168 18.151 92 16 2 


ping 172.17.43.71 


2.2 ”通过 Open vSwitch 打 通 网络 


首先 ， 确 保 节 点 192.168.18.128 的 Docker0 采 用 172.17.43.0/24 网 
段 ， 而 192.168.18.131 的 Docker0 采 用 172.17.42.0/24 网 段 ， 对 应 参数 为 
docker daemon 的 启动 参数 --bip 设 置 的 值 。 


Open vSwitch 的 安装 和 配置 方法 如 下 。 


1) 在 两 个 Node 上 安装 ovs 


# yum install openvswitch-2.4.0-1.x86_64.rpm 


禁止 selinux， 配 置 后 重启 Linux: 


# vi /etc/selinux/config 


SELINUX=disabled 


AA Open vSwitch 的 服务 状态 ， 应 该 局 动 两 个 进程 : ovsdb-server 


与 ovs-vswitchd ° 


# service openvswitch status 
ovsdb-server is running with pid 2429 


ovs-vswitchd is running with pid 2439 


AF Open vSwitch 的 相关 日 志 ， 确 认 没 有 异常 


# more /var/log/messages |grep openv 
Nov 2 03:12:52 docker128 openvswitch: Starting ovsdb- 
server [ OK | 
Nov 2 03:12:52 docker128 openvswitch: Configuring 
Open vSwitch system IDs [ OK ] 
Nov 2 03:12:52 docker128 kernel: openvswitch: Open 
vSwitch switching datapath 
Nov 2 03:12:52 docker128 openvswitch: Inserting 


openvswitch module [ OK ] 


TER Lute ee BEAST SR ED BET SEB © 
) 创建 网 桥 和 GRE 隧 道 


接 下 来 需要 在 每 个 Node 上 建立 ovs 的 网 桥 br0， 然 后 在 网 桥 上 创建 


一 个 GRE 隧 道 连接 对 端 网 桥 ， 最 后 把 ovs 的 网 桥 br0 作 为 一 个 端口 连接 
到 docker0 这 个 Linux 网 桥 上 (可 以 认为 是 交换 机 互联 ， 这 样 一 来 ， 
两 个 节点 机 器 上 的 docker0 网 段 束 能 互通 了 。 


下 面 以 节点 机 器 192.168.18.131 为 例 ， 具 体 的 操作 步骤 如 下 。 
(1) 创建 ovs 网 桥 : 


# ovs-vsctl add-br bro 


(2) 创建 GRE 隧 道 连接 对 端 ，remote_ip 为 对 端 eth0 的 网 卡 地 址 : 


# ovs-vsctl add-port brO grei1 -- set interface grei 


type-gre option:remote ip-192.168.18.128 


(3) 添加 br0 到 本 地 docker0， 使 得 容器 流量 通过 OVS 流 经 


tunnel: 


# brctl addif dockerO bro 


(4) 启动 br0 与 docker0 网 桥 : 


# ip link set dev brO up 


# ip link set dev dockerO up 


(5) 添加 路 由 规则 。 由 于 192.168.18.128 5j 192.168.18.131 的 
docker0 网 段 分 别 为 172.17.43.0/24 与 172.17.42.0/24， 这 两 个 网 段 的 路 由 
都 需要 经 过 本 机 的 docker0 网 桥 路 由 ， 其 中 一 个 24 网 段 是 通过 OVS 的 
GRE 隧 道 到 达 对 端的 ， 因 此 需要 在 每 个 Node 上 添加 通过 docker0 网 桥 转 
发 的 172.17.0.0/16 段 的 路 由 规则 : 


# ip route add 172.17.0.0/16 dev dockerO 


(6) 18 Bee Docker 自 带 的 Iptables 规 则 及 Linux 的 规则 ， 后 者 存在 拒 
绝 icemp 报 文通 过 防火 墙 的 规则 : 


# iptables -t nat -F; iptables -F 


1£192.168.18.131 E 5E EX, Luteo, 1:192.168.18.128 1? AHT] 
样 的 操作 ， 注 意 ，GRE 隧 道里 的 也 地 址 要 改 为 对 端 节 点 
(192.168.18.131) 的 IP 地 址 。 


配置 完成 后 ，192.168.18.131 的 IP 地 址 、docker0 的 IP 地 址 及 路 由 等 
重要 信息 显示 如 下 : 


# ip addr 
1: lo: <LOOPBACK,UP,LOWER UP> mtu 65536 qdisc noqueue 
state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
2: ethO: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1500 
qdisc pfifo_fast state UP qlen 1000 
link/ether 00:0c:29:55:5e:c3 brd ff: ff: ff: ff: fF: FF 
inet 192.168.18.131/24 brd 192.168.18.255 scope 
global dynamic ethO 
valid lft 1369sec preferred lft 1369sec 
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc 
noop state DOWN 
link/ether a6:15:c3:25:cf:33 brd ff:ff:ff:ff:ff:ff 
4: brO: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1500 


qdisc noqueue master dockerO state UNKNOWN 


link/ether 92:8d:d0:a4:ca:45 brd ff: ff: ff: ff: ff: fF 
5: docker0: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 1500 
qdisc noqueue state UP 
link/ether 02:42:44:8d:62:11 brd ff:ff:ff:ff:ff:ff 
inet 172.17.42.1/24 scope global dockerO 


valid lft forever preferred lft forever 


同样 ，192.168.18.128 节 点 的 重要 信息 如 下 : 


# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid lft forever preferred lft forever 
2: ethO: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1500 
qdisc pfifo fast state UP qlen 1000 
link/ether 00:0c:29:e8:02:c7 brd ff:ff:ff:ff:ff:ff 
inet 192.168.18.128/24 brd 192.168.18.255 scope 
global dynamic ethO 
valid lft 1356sec preferred lft 1356sec 
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc 
noop state DOWN 
link/ether fa:6c:89:a2:f2:01 brd ff:ff:ff:ff:ff:ff 
4: brO: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1500 


qdisc noqueue master dockerO state UNKNOWN 


Tb: 


link/ether ba:89:14:e0:7f:43 brd ff:ff:ff:ff:ff:ff 
5: docker0: «BROADCAST, MULTICAST,UP,LOWER UP» mtu 1500 
qdisc noqueue state UP 
link/ether 02:42:63:a8:14:d5 brd ff:ff:ff:ff:ff:ff 
inet 172.17.43.1/24 scope global dockerO 


valid lft forever preferred lft forever 


3) 两 个 Node 上 容器 之 间 的 互通 测试 


首先 ， 在 192.168.18.128 节 点 上 ping192.168.18.131 上 的 docker0 地 


172.17.42.1， 验 证 网 络 互通 性 : 

# ping 172.17.42.1 

PING 172.17.42.1 (172.17.42.1) 56(84) bytes of data. 

64 bytes from 172.17.42.1: icmp_seq=1 ttl-64 time=1.57 
ms 


64 bytes from 172.17.42.1: icmp seq-2 ttl-64 
time-0.966 ms 


64 bytes from 172.17.42.1: icmp seq-3 ttl-64 time-1.01 


ms 

64 bytes from 172.17.42.1: icmp seq-4 ttl-64 time-1.00 
ms 

64 bytes from 172.17.42.1: icmp seq-5 ttl-64 time-1.22 
ms 


64 bytes from 172.17.42.1: icmp seq-6 ttl-64 


time-0.996 ms 


下 面 我 们 通过 tshark 抓 包工 具 来 分 析 流 量 走 向 。 首 先 ， 在 
192.168.18.128 节 点 上 监听 br0 上 有 是否 有 GRE 报 文 ， 执 行 下面 的 命令 ， 
我 们 发 现 br0 上 并 没有 GRE 报 文 : 


# tshark -i brO -R ip proto GRE 
tshark: -R without -2 is deprecated. For single-pass 
filtering use -Y. 
Running as user "root" and group "root". This could be 
dangerous. 
Capturing on 'br6o' 


^C 


Meho EJE, WAH T GREAT ping GROM, ViBHGRE 
征 在 承载 网 的 物理 网 上 完成 的 封包 过 程 : 


# tshark -i ethO -R ip proto GRE 
tshark: -R without -2 is deprecated. For single-pass 
filtering use -Y. 
Running as user "root" and group "root". This could be 
dangerous. 
Capturing on 'ethOQ' 
1 0.000000  Á172.17.43.1 -> 172.17.42.1 ICMP 136 
Echo (ping) request id=0x0970, seq=180/46080, ttl-64 
2 0.000892 172.17.42.1 -> 172.17.43.1 ICMP 136 
Echo (ping) reply id=0x0970, seq=180/46080, ttl-64 
(request in 1) 


2 3 1.002014 172.17.43.1 -> 172.17.42.1 ICMP 136 


Echo (ping) request id=0x0970, seq=181/46336, ttl-64 
4 1.002916  172.17.42.1 -> 172.17.43.1 ICMP 136 
Echo (ping) reply id-0x0970, seq=181/46336, ttl-64 
(request in 3) 
4 5 2.004101 172.17.43.1 -> 172.17.42.1 ICMP 136 
Echo (ping) request id=0x0970, seq-182/46592, ttl-64 


至 此 ， 基 于 OVS 的 网 络 搭 建成 功 ， 由 于 GRE 是 点 对 点 隧道 通信 方 
式 ， 所 以 如 果 有 多 个 Node， 则 需要 建立 Nx (N-1) 条 GRE 隧 道 ， 即 所 
有 Node 组 成 一 个 网 状 的 网 络 ， 实 现 全 网 互通 。 


3. 直 接 路 由 


通过 在 每 个 Node 上 添加 到 其 他 Node 上 docker0 的 静态 路 由 规则 , 
就 可 以 将 不 同 物理 机 的 docker0 网 桥 互 联 和 互通 。 图 2.3 描 述 了 在 两 个 
Node 之 间 打 通 网 络 的 情况 。 


Node1 Node2 
AC E 28 
Pod 1 j Pod 2 
容器 1 容器 2 容器 1 容器 2 
共享 网 络 | 共享 网 络 
空间 Ez | 空间 o 
xi x 
x: > 
L; = 
wD x 9: p<} 
Docker0 网 桥 | Docker0 网 桥 
o I 
一 1 
sar > 
a 


no] re 
7****ssasecenscsecesecat*? 


Al2.3 ”以 直接 路 由 方式 实现 Pod 到 Pod 的 通信 


使 用 这 种 方案 ， 只 需要 在 每 个 Node 的 路 由 表 中 增加 到 对 方 docker0 
的 静态 路 由 转发 规则 。 


例如 Pod1 所 在 docker0 网 桥 的 王子 网 是 10.1.10.0 ，Node 地 址 为 


192.168.1.128;， 而 Pod2 所 在 docker0 网 桥 的 卫 子 网 是 10.1.20.0，Node 地 
址 为 192.168.1.129 ° 


在 Nodel 上 用 route add 命 令 增 加 一 条 到 Node2 上 docker0 的 静态 路 由 
规则 : 


route add 


-net 10.1.20.0 netmask 255.255.255.0 gw 
192.168.1.129 


同样 ， 在 Node2 上 增加 一 条 到 Nodel 上 docker0 的 静态 路 由 规则 : 


route add -net 10.1.10.0 netmask 255.255.255.0 gw 
192.168.1.128 


在 Nodel 上 通过 ping 命 令 验 证 到 Node2 上 docker0 的 网 络 连通 性 。 这 
里 10.1.20.1 为 Node2 上 docker0 网 桥 自身 的 IP 地 址 。 


$ ping 10.1.20.1 
PING10.1.20.1 (10.1.20.1) 56(84) bytes of data. 


64 bytes from 10.1.20.1: icmp_seq=1 ttl-62 time=1.15 


ms 

64 bytes from 10.1.20.1: icmp seq-2 ttl-62 time=1.16 
ms 

64 bytes from 10.1.20.1: icmp seq-3 ttl-62 time-1.57 
ms 


可 以 看 到 ， 路 由 转发 规则 生效 ，Node1 可 以 直接 访问 到 Node2 上 的 
docker0 网 桥 ， 进 一 步 也 可 以 访问 到 属于 docker0 网 段 的 容 絮 应 用 了。 


不 过 ， 集 群 中 机 句 的 数量 通常 可 能 很 多 。 假 设 有 100 台 服务 器 ， 那 
么 谍 需 要 在 每 台 服 务 器 上 手工 添加 到 男 外 99 侣 服务 器 docker0 的 路 由 规 
则 。 为 了 减少 手工 操作 ， 可 以 使 用 Quagga 软 件 来 实现 路 由 规则 的 动态 
添加 。Quagga 软 件 的 主页 为 http://www.quagga.net ° 


除了 在 每 台 服 务 器 上 安装 Quagga 软 件 并 启动 ， 还 可 以 使 用 Quagga 
容器 来 运行 (例如 index.alauda.cn/georce/router) 。 在 每 台 Node 上 下 载 


Dockers 5: 


$ docker pull index.alauda.cn/georce/router 


Aí Quagga ar Hi, Hae HDR ET Node 上 docker0 网 桥 的 子 网 
地 址 不 能 重合 ， 也 不 能 与 物理 机 所 在 的 网 络 重重， 这 需要 网 络 管理 员 
的 仔细 规划 。 


下 面 以 3 个 Node 为 例 ， 每 台 Node 的 docker0 网 桥 的 地 址 如 下 (前 提 
是 Node 物 理 机 的 IP 地 址 不 是 10.1.X.X 地 址 段 ): 


Node 1: # ifconfig dockerO 10.1.10.1/24 
Node 2: # ifconfig dockerO 10.1.20.1/24 


Node 3: # ifconfig dockerO 10.1.30.1/24 


然后 在 每 个 Node 上 启动 Quagga 容 器 。 需 要 说 明 的 是 ，Quagga 需 要 
以 --privileged 特 权 模 式 运行 ， 并 且 指 定 --net=host， 表 示 直 接 使 用 物理 
机 的 网 络 : 


$ docker run -itd --name=router --privileged 


net=host index.alauda.cn/georce/router 


局 动 成 功 后 ，Quagga 会 相互 学 习 来 完成 到 其 他 机 恬 的 docker0 路 由 
规则 的 添加 。 


一 段 时 间 后 ， 在 Nodel 上 使 用 route-n 命 令 来 查看 路 由 表 ， 可 以 看 
到 Quagga 目 动 添加 了 两 条 到 Node2 和 到 Node3 上 docker0 的 路 由 规则 。 


# route -n 


Kernel IP routing table 


Destination Gateway Genmask 

Flags Metric Ref Use Iface 

0.0.0.0 192.168.1.128 0.0.0.0 UG 
0 0 0 ethO 

10.1.10.0 0.0.0.0 255.255.255.0 U 
0 0 OdockerO 

10.1.20.0 192.168.1.129 255.255.255.0 UG 
20 0 0 etho 

10.1.30.0 192.168.1.130 255.255.255.0 UG 
20 0 0 etho 


在 Node2 上 查看 路 由 表 ， 可 以 看 到 目 动 添加 了 两 条 到 Node1 和 
Node3 上 docker0 的 路 由 规则 。 


# route -n 


Kernel IP routing table 


Destination Gateway Genmask Flags 
Metric Ref Use Iface 
0.0.0.0 192.168.1.129 0.0.0.0 UG 
0 0 0 ethO 
10.1.20.0 0.0.0.0 255.255.255.0 U 
0 0 © dockerO 
10.1.10.0 192.168.1.128 255.255.255.0 UG 


20 0 © etho 


10.1.30.0 192.168.1.130 255.255.255.0 


20 0 © etho 


至 此 ， 所 有 Node 上 的 docker0 都 可 以 互联 互通 了 ° 


UG 


2.2 ”kubect 命 令 行 工 具 用 法 详解 


kubect 作 为 客户 端 CLI 工 具 ， 可 以 让 用 户 通 过 命令 行 的 方式 对 
Kubernetes 集 群 进行 操作 。 本 节 对 kubect 的 子 命令 和 用 法 进行 详细 说 
明 o 


2.2.1 kubectl 用 法 概 壕 


kubectl 命 令 行 的 语法 如 下 : 
$ kubectl [command] [TYPE] [NAME] [flags] 


HH, command ^ TYPE ` NAME ` flags XL All F e 


(1) command: 子 命令 ， 用 于 操作 Kubernetes 集 群 资 源 对 象 的 命 


令 ， 例 如 create、delete、describe、get、apply 等 。 


(2) TYPE: 资源 对 象 的 类 型 ， 区 分 大 小 写 ， 能 以 单数 形式 、 复 
数 形式 或 者 简写 形式 表示 。 例 如 以 下 3 种 TYPE 是 等 价 的 。 


$ kubectl get pod pod1 
$ kubectl get pods podi 
$ kubectl get po podi 


(3 NAME: 资源 对 象 的 名 称 ， 区 分 大 小 写 。 如 果 不 指定 名 称 ， 
则 系统 将 返回 属于 TYPE 的 全 部 对 象 的 列表 ， 例 如 $kubectl get pods 将 
返回 所 有 Pod 的 列表 。 


(4) flags: kubectl 子 命令 的 可 选 参数 ， 例 如 使 用 “-s” 指 定 
apiserver 的 URL 地 址 而 不 用 默认 值 。 


kubectl 可 操作 的 资源 对 象 类 型 如 表 2.9 所 示 。 


42.9 kubecd 可 操作 的 资源 对 象 类 型 


资源 对 象 的 名 称 


componentstatuses 


daemonsets 


deployments 


events 


endpoints 


ep 


horizontalpodautoscalers 


hpa 


ingresses 


ing 


jobs 


limitranges 


limits 


nodes 


namespaces 


pods 


persistentvolumes 


persistentvolumeclaims 


resourcequotas 


replicationcontrollers 


secrets 


serviceaccounts 


services 


在 一 个 命令 行 中 也 可 以 同时 对 多 


个 资源 对 象 进行 操作 ， 以 多 个 


TYPE 和 NAME 的 组 合 表 示 ， 示 例如 下 。 


。 获取 多 个 Pod 的 信息 : 


$ kubectl get pods pod1 pod2 


。 获取 多 种 对 象 的 信息 : 


$ kubectl get pod/pod1 rc/rc1 


。 同时 应 用 多 个 yam] 文 件 ， 以 多 个 -f file 参 数 表示 : 


$ kubectl get pod -f podi.yaml -f pod2.yaml 
$ kubectl create -f podi.yaml -f rci.yaml -f 


servicei.yaml 


2.2.2 ”kubectl 子 命令 


kubectl 的 子 命令 非常 丰 
包括 资源 对 象 的 创建 、 删 除 


A VERB 


Hl 


4 


命令 如 表 2.10 所 示 。 


annotate 


api-versions 


autoscale 


322.10 ”kubectl 子 命令 


kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) 
KEY_1=VAL 1... 
kubectl api-versions [flags] 


KEY N-VAL N [—resource-version=version] [flags] 


kubectl apply -f FILENAME [flags] 


kubectl attach POD -c CONTAINER [flags] 
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) 
[--min-MINPODS] —-max-MAXPODS [--cpu-percent-CPU] [flags] 


， 泗 盖 了 对 Kubernetes 集 群 的 主要 操作 ， 
查看 、 修 改 、 配 置 、 


UA Am. Fife 


运行 等 


详解 


添加 或 更 新 资源 对 象 的 annotation 
信息 
列 出 当前 系统 支持 的 API 版 本 列表 ， 


格式 为 “group/version” 


从 配置 文件 或 stdin 中 对 资源 对 象 进 
行 配置 更 新 

附着 到 一 个 正在 运行 的 容器 上 

对 Deployment, ReplicaSet 或 
ReplicationController 进行 水 平 自动 
扩 缩 容 的 设置 


cluster-info 


kubectl cluster-info [flags] 
kubectl cluster-info [command] 


显示 集群 信息 


completion 


kubectl completion SHELL [flags] 


输出 shell 命令 的 执行 结果 码 (bash 
或 zsh) 


config 


kubectl config SUBCOMMAND [flags] 
kubectl config [command] 


修改 kubeconfig 文件 


kubectl convert -f FILENAME [flags] 
kubectl cordon NODE [flags] 


转换 配置 文件 为 不 同 的 API 版 本 
将 Node 标记 为 unschedulable, 即 * 隔 
离 ” 出 集群 调度 范围 


kubectl create -f FILENAME [flags] 
kubectl create [command] 


从 配置 文件 或 stdin 中 创建 资源 对 象 


kubectl delete ([-f FILENAME] | TYPE [(NAME | -1 label | --all)]) 
[flags] 


根据 配置 文件 、stdin、 资 源 名 称 或 
label selector 删除 资源 对 象 


kubectl describe (-f FILENAME | TYPE [NAME PREFIX | /NAME | 
-1 label]) [flags] 


描述 一 个 或 多 个 资源 对 象 的 详细 信 
息 


kubectl drain NODE [flags] 


首先 将 Node 设置 为 unschedulable, 
然后 删除 该 Node 上 运行 的 所 有 Pod, 
但 不 会 删除 不 由 apiserver 管理 的 Pod 


kubectl edit (RESOURCE/NAME | -f FILENAME) [flags] 


编辑 资源 对 象 的 属性 ， 在 线 更 新 


o 详细 的 子 


续 表 
| exec | kubect exec POD [-e CONTAINER] - COMMAND [args] [flag] | 执行 一 个 容器 中 的 命令 | 
expose kubectl expose (-f FILENAME | TYPE NAME) [--port=port] | 将 已 经 存在 的 一 个 RC. Service. 

[--protocol=TCP/UDP] [--target-port=number-or-name] [--name=name] | Deployment 或 Pod 暴露 为 一 个 新 的 
[--external-ip=external-ip-of-service] [--type=type] [flags] Service 
kubectl get [(-0|--output=)json!yamliwide|go-template=..|go-template- | 显示 一 个 或 多 个 资源 对 象 的 概要 信 
file=...{jsonpath=...|jsonpath-file=..] (TYPE [NAME | -l label) | TYPE/ | & 
NAME ...) [flags] 


kubectl label [--overwrite] (-f FILENAME | TYPE NAME) 
KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [flags] 
|l | kubect logs [A Ep] POD [-e CONTAINER] [as] | RTM 。 | 


县 的 值 进行 修改 
port-forward | kubect port-forward POD [LOCAL PORT-JREMOTE PORT 
L.[LOCAL PORT N]REMOTE PORT N] [flags] 端口 号 ， 通 常用 于 测试 工作 
OE AES M aua 
[-www-prefix=prefix] [-api-prefix-prefix] [flags] 


| replace | kubectl replace FILENAME [flags] | 从 配置 文件 或 shtin 普 换 资 源 对 象 | 
kubectl rolling-update OLD CONTROLLER NAME (NEW_ | 对 RC 进行 滚动 升级 
CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | 
-f NEW_CONTROLLER_SPEC) [flags] 
kubectl rollout SUBCOMMAND [flags] 对 Deployment 进行 管理 ， 可 用 操作 
kubectl rollout [command] 包括 : history. pause. resume, undo, 


status 
kubectl run NAME --image=image [--env="key=value”] [--port=port] | 基于 一 个 镜 在 Kubemetes 集群 上 启 
[--replicas=replicas] [-dry-run-bool] [-overrides=inline-json] | 动 一 个 Deployment 
[-command] -- [COMMAND] [ares...] [flags] 


kubectl scale [--resource-version=version] [--current-replicas=count] | 3° 2%. 4 1t — (T Deployment. 
EM — ——— —m o3 
~) kubectl set SUBCOMMAND [flags] 设置 资源 对 象 的 某 个 特定 信息 ， 目 

kubectl set [command] 前 仅 支 持 修 改 容器 的 镜像 

kubectl taint NODE NAME KEY_1=VAL_1-TAINT EFFECT 1 ... | 设置 Node 的 taint 信息 ， 用 于 将 特 
7 KEY N-VAL N:TAINT EFFECT. N [flags] 定 的 Pod 调度 到 特定 的 Node 的 操 

作 ， 为 Alpha 版 本 功能 

| mcordon — | 


wcordon Node 设置 为 schedulable 


打印 系统 的 版 本 信息 


kubectl 命 令 行 的 公共 启动 参 


表 2.11 ”kubectl 命 令 行 公 


参数 名 和 取 值 示例 
--alsologtostderr[=false] 


2.2.3 kubectl ZA I| 3& 


数 如 表 2.11 所 示 。 
共 参 数 


设置 为 tue 表示 将 日 志和 输出 到 文件 的 同时 输出 到 stderr 


—as-"" 


设置 本 次 操作 的 用 户 名 


--certificate-authority="" 


—client-certificate-"" 


用 于 CA 授权 的 cert 文件 路 径 
用 于 TLS 的 客户 端 证 书 文件 路 径 


--client-key="" 


用 于 TLS 的 客户 端 key 文件 路 径 


--cluster="" 


设置 要 使 用 的 kubeconfig 中 的 cluster 名 


--context="" 


设置 要 使 用 的 kubeconfig 中 的 context 名 


--insecure-skip-tls-verify[=false] 


设置 为 true 表示 跳 过 TLS 安全 验证 模式 ， 将 使 得 HTTPS 连接 不 安全 


--kubeconfig="" 


kubeconfig 配置 文件 路 径 , 在 配置 文件 中 包括 Master 地 址 信息 及 必要 的 认证 信息 


--log-backtrace-at=:0 


记录 日 志 每 到 “file: 行 号 ”时 打印 一 次 stack trace 


--log-dir-"" 


日 志文 件 路 径 


--log-flush-frequency-5s 


设置 flush. 日 志文 件 的 时 间 间 隔 


--logtostderr[-true] 


设置 为 tue 表示 将 日 志 输出 到 stderr， 不 输出 到 日 志文 件 


--match-server-version[=false] 


设置 为 tue JT P RUBORE TES HR 


--namespace-"" 


设置 本 次 操作 所 在 的 namespace 


--password="" 


设置 apiserver 的 basic authentication 的 密码 


-S, —server-"" 


设置 apiserver 的 URL 地 址 ， 默 认为 localhost:8080 


--stderrthreshold=2 


--token="" 


在 该 threshold 级 别 之 上 的 日 志 将 输出 到 stderr 
设置 访问 apiserver 的 安全 token 


--user="" 


指定 kubeconfig 用 户 名 


--username="" 


--v=0 


设置 apiserver 的 basic authentication 的 用 户 名 
glog 日 志 级 别 


每 个 子 命令 
以 通过 $kubectl[command]--help 命 令 


--vmodule= 


(如 create、delete、get 等 ) j 


glog 基于 模块 的 详细 日 志 级 别 


还 有 特定 的 flags 参 数 ， 
邻 进行 查看 。 


2.2.4 ”kubectl 输 出 格式 


kubectl 命 令 可 以 用 多 种 格式 对 结果 进行 显示 ， 输 出 的 格式 通过 -o 
参数 指定 : 


$ kubectl [command] [TYPE] [NAME] -o=<output_format> 


根据 不 同 子 命令 的 输出 结果 ， 可 选 的 输出 格式 如 表 2.12 所 示 。 
表 2.12 ”kubect 命 令 输出 格式 列表 


输出 格式 
-o=custom-columns=<spec> 根据 自 定义 列 名 进行 输出 ， 以 逗号 分 隔 
-o=custom-columns-file=<filename> 从 文件 中 获取 自 定 义 列 名 进行 输出 
-o-json 以 ISON 格式 显示 结果 


-o=jsonpath=<template> 输出 jsonpath 表达 式 定义 的 字段 信息 


-o=jsonpath-file=<filename> 输出 jsonpath 表达 式 定义 的 字段 信息 ， 来 源 于 文件 
-o=name 仅 输出 资源 对 象 的 名 称 

-o=wide 输出 额外 信息 。 对 于 Pod， 将 输出 Pod 所 在 的 Node 名 
-o=yaml 以 yaml 格式 显示 结果 


常用 的 输出 格式 示例 如 下 。 
(1) 显示 Pod 的 更 多 信息 : 
$ kubectl get pod <pod-name> -o wide 
(2) 以 yaml 格 式 显 示 Pod 的 详细 信息 : 


$ kubectl get pod <pod-name> -0 yaml 


(3) 以 自 定 义 列 名 显示 Pod 的 信息 : 


$ kubectl get pod <pod-name>  -o=custom- 


columns=NAME: .metadata.name, RSRC: .metadata. resourceVersion 


(4) 基于 文件 的 自 定 义 列 名 输出 : 


$ kubectl get pods <pod-name> -o=custom-columns- 


file=template.txt 


template.txt 文 件 的 内 容 为 : 


NAME RSRC 

metadata.name metadata. resourceVersion 
hy D 
输出 结果 为 : 

NAME RSRC 

pod-name 52305 


另外 ， 还 可 以 将 输出 结 末 按 某 个 字段 排序 ， 通 过 --sort-by 参 数 以 
jsonpath 表 达 式 进行 指定 : 


$ kubectl [command] [TYPE] [NAME] --sort-by- 


<jsonpath_exp> 


例如 ， 按 照 名 字 进 行 排序 : 


$ kubectl get pods --sort-by=.metadata.name 


2.2.5 kubectl 探 作 示 例 


本 闻 对 一 些 常用 的 kubectl 操 作 进 行 示例 。 


1. 创 建 资 源 对 象 
根据 yaml 配 置 文件 一 次 性 创建 service 和 rc: 


$ kubectl create -f my-service.yaml -f my-rc.yaml 


TR 28 «directory» H 3 RATA .yaml ^ .yml ` json SCF HY XE SHAT 8) 
建 操作 : 


$ kubectl create -f <directory> 


2. 查 看 资源 对 象 
查看 所 有 Pod 列 表 : 

$ kubectl get pods 
查看 rc 和 service 列 表 : 


$ kubectl get rc,service 


3. 描 述 资源 对 象 
显示 Node 的 详细 信息 : 


$ kubectl describe nodes <node-name> 


显示 Pod 的 详细 信息 JUN 


$ kubectl describe pods/<pod-name> 


显示 由 RC 管理 的 Pod 的 信息 : 


$ kubectl describe pods <rc-name> 


4. 删 除 资 源 对 象 
基于 pod.yaml 定 义 的 名 称 删除 Pod: 
$ kubectl delete -f pod.yaml 
删除 所 有 包含 某 个 label 的 Pod 和 service: 
$ kubectl delete pods,services -1 name=<label-name> 
删除 所 有 Pod: 


$ kubectl delete pods --all 


$ kubectl exec <pod-name> date 


指定 Pod 中 某 个 容器 执行 date 命 令 : 


$ kubectl exec <pod-name> -c <container-name> date 


M bashk Pod FE LAASHTTY, THIBTOGGRAS: 


$ kubectl exec -ti <pod-name> -c <container-name> /bin/bash 


查看 容器 输出 到 stdout 的 日 志 : 


$ kubectl logs <pod-name> 


Pine A Aa A, FS Ftal -{ 命 令 的 结 


$ kubectl logs -f <pod-name> -c <container -name> 


2.3 ” ”Guestbook 示例 : Hello World 


在 对 Kubernetes 的 容 右 应 用 进行 详细 说 明之 前 ， 让 我 们 移 通 过 一 
个 由 3 个 微服 务 组 成 的 留言 板 (Guestbook) 系统 的 搭建 ， 对 Kubernetes 
对 容 絮 应 用 的 基本 操作 和 用 法 进行 初步 介绍 。 本 章 后 面 的 章 市 将 基于 
该 案例 和 其 他 示例 ， 进 一 步 深入 Pod、RC、Service 等 核心 对 象 的 用 法 
和 技巧 ， 对 Kubernetes 的 应 用 管理 进行 全 面 讲解 。 


Guestbook 留 言 板 系 统 将 通过 Pod、RC、Service 等 货源 对 象 搭建 完 
成 ， 成 功 启 动 后 在 网 页 中 显示 一 条 “Hello World” 留 言 。 其 系统 架构 是 
一 个 基于 PHP+Redis 的 分 布 式 Web 应 用 ， 前 端 PHP Web 网 站 通过 访问 后 
端的 Redis 来 完成 用 户 留言 的 查询 和 添加 等 功能 。 同 时 Redis 以 
Master+Slave 的 模式 进行 部 署 ， 实 现 数据 的 读 写 分 离 能 力 。 


留言 板 系统 的 部 署 架 构 如 图 2.4 所 示 。Web 层 是 一 个 基于 PHP 页 面 
的 Apache 服 务 ， 启 动 3 个 实例 组 成 集群 ， 为 客户 端 〈 例 如 浏览 器 ) 对 
网 站 的 访问 提供 负载 均衡 。Redis Master 启 动 1 个 实例 用 于 写 操作 CAS 
加 留言 ) ，RedisSlave 启 动 两 个 实例 用 于 读 操 作 〈 读 取 留 言 ) 。 
RedisMaster 与 Slave 的 数据 同步 由 Redis 具 备 的 数据 同步 机 制 完成 。 


redis-slave 


图 2.4 Bam Ashe RMA 


在 本 例 中 将 要 用 到 3 个 Docker 镜 像 ， 下 载 地 址 为 
https://hub.docker.com/u/kubeguide/ ° 


e redis-master: 用 于 前 端 Web 应 用 进行 “ 写 ” 留 言 操 作 的 Redis 服 务 ， 

其 中 已 经 保存 了 一 条 内 容 为 “Hello World! ”的 留言 。 

guestbook-redis-slave: FA T Bi Ym Web M Fl iH 47 “ik” BB PREY 

Redis 服 务 ， 并 与 Redis-Master 的 数据 保持 同步 。 

aF -php-frontend: PHP Web 服 务 ， 在 网 页 上 展示 留言 的 内 
， 世 提供 一 个 文本 输入 框 供 访 客 添 加 留言 。 


如 图 2.5 所 示 为 Hello World 案 例 所 采用 的 Kubernetes 部 署 架 构 ， 这 
里 Master 与 Node 的 服务 处 于 同一 个 虚拟 机 中 。 通 过 创建 redis-master 服 
务 、redis-slave 服 务 和 php-frontend 服 务 来 实现 整个 系统 的 搭建 。 


SS 
e 
浏览 器 访问 


d \ frontend Service 


redis-slave | redis-slave Service 
ay ab. ! 
I 


虚拟 机 


图 2.5 ”Kubernetes 部 署 染 构 


2.3.1 创建 redis-master RC 和 Service 


我 们 可 以 先 定 义 Service， 然 后 定义 一 个 RC 来 创建 和 控制 相关 联 的 
Pod， 或 者 先 定义 RC 来 创建 Pod， 然 后 定义 与 之 关联 的 Service， 这 里 我 
们 采用 后 一 种 方法 。 


首先 为 redis-master 创 建 一 个 名 为 redis-master 的 RC 定义 文件 redis- 
master-controller.yaml。yaml 的 语法 类 似 于 PHP 的 语法 ， 对 于 空格 的 个 
数 有 严格 的 要 求 ， 详 见 http:/yaml.org ° 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 


spec: 


containers: 

- name: master 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


HB, kind Ex B5 (& X “ReplicationController”, 3&z& 3X Æ — A^ 
RC; spec.selector 是 RC 的 Pod 选 择 器 ， 即 监控 和 管理 拥有 这 些 标签 
(Label) 的 Pod 实 例 ， 确 保 当 前 集群 上 始终 有 且 仅 有 replicas 个 Pod 实 例 
在 运行 ， 这 里 我 们 设置 replicas=1 表 示 只 运行 一 个 〈 名 为 redis-master 
的 ) Pod 实 例 ， 当 集群 中 运行 的 Pod 数 量 小 于 replicas 时 ，RC 会 根据 
spec. n um 3IHJPod3zffl, labels P'ETR 
定 了 该 Pod 的 标签 ， 注意 ， 这 里 的 labels 必 须 匹 配 RC 的 spec.selector， 否 
则 此 RC 就 会 陷入 “只 Eo m 中 ， 永 无 翻身 之 时 。 


创建 好 redis-master-controller.yaml 文 件 以 后 ， 我 们 在 Master 世 点 执 
TM: kubectl create-f<config_file>， 将 它 发 布 到 Kubernetes 集 群 中 ， 
就 完成 了 redis-master 的 创建 过 程 : 


N 


$ kubectl create -f redis-master-controller.yaml 


replicationcontroller "redis-master" created 


系统 提示 “redis-master" 表 示 创 建成 功 。 然 后 我 们 用 kubect 命 令 查 
看 刚刚 创建 的 redis-master: 


$ kubectl get rc 


NAME DESIRED CURRENT AGE 


redis-master 1 1 5m 


接 下 来 运行 kubectl get pods 命 令 来 查看 当前 系统 中 的 Pod 列 表 信 
息 ， 我 们 看 到 一 个 名 为 redis-master-xxxxx 的 Pod 实例 ， 这 是 Kubernetes 
根据 redis-master 这 个 RC 的 定义 目 动 创建 的 Pod。RC 会 给 每 个 Pod 实 例 
在 用 户 设置 的 name 后 补充 一 段 JUID， 以 区 分 不 同 的 实例 。 由 于 Pod 的 
调度 和 创建 需要 论 费 一 定 的 时 间 ， 比 如 需要 一 定 的 时 间 来 确定 调度 到 
哪个 节点 上 ， 以 及 下 载 Pod 的 相关 镜像 ， 所 以 一 开始 我 们 看 到 Pod 的 状 
态 将 显示 为 Panding。 当 Pod 成 功 创建 完成 以 后 ， 状 态 会 被 更 新 为 
Running ° 如果 Pod 一 直 处 于 Pending 状 态 ， 则 请 参看 第 5 章 的 查 错 说 


明 。 
$ kubectl get pods 
NAME READY STATUS 
RESTARTS AGE 
redis-master-b03io 1/1 Running 
0 1h 


redis-master Pod 已 经 创建 并 正常 运行 了 ， 接 下 来 我 们 就 创建 一 个 
与 之 关联 的 Service (ARB) 定义 文件 (文件 名 为 redis-master- 
service.yaml) ， 完 整 的 内 容 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 

name: redis-master 


labels: 


name: redis-master 
spec: 
ports: 
- port: 6379 
targetPort: 6379 
selector: 


name: redis-master 


其 中 metadata.name Æ Service 的 服务 名 ( ServiceName ) , 
spec.selector 人 确定 了 选择 哪些 Pod， 本 例 中 的 定义 表明 将 选择 设置 过 
name=redis-master 标 签 的 Pod。port 属 性 定义 的 是 Service 的 虚拟 端口 


=j 


55, targetPortis Vt 7a x Jn im Pod N Aas hy A a UT BS L1. 


运行 kubectl create tip 4 | £& iZ service: 


$ kubectl create -f redis-master-service.yaml 


service "redis-master" created 


系统 提示 “service”redis-master“created” 表 示 创 建成 功 。 然 后 运行 
kubectl get 命 令 可 以 查看 到 刚刚 创建 的 service: 


$ kubectl get services 
NAME CLUSTER-IP EXTERNAL - IP 
PORT(S) AGE 


redis-master 169.169.208.57«none» 
6379/TCP 13m 


注意 到 redis-master 服 务 被 分 配 了 一 个 值 为 169.169.208.57 的 虚拟 IP 
地 址 ， 随 后 ，Kubernetes 集 群 中 其 他 新 创建 的 Pod 束 可 以 通过 这 个 虚拟 
IP 地 址 + 端口 6379 来 访问 这 个 服务 了 。 在 本 例 中 将 要 创建 的 redis-slave 
和 frontend 两 组 Pod 都 将 通过 169.169.208.57: 63795 来 访问 redis-master 服 


务 。 


但 由 于 了 地 址 是 在 服务 创建 后 由 Kubernetes 系 统 目 动 分 配 的 ， 在 其 

他 Pod 中 无 法 预先 知道 某 个 Service 的 虚拟 下 地 址 ， 因 此 需要 一 个 机 制 来 

找到 这 个 服务 。 为 此 ，Kubernetes 巧 妙 地 使 用 了 Linux 环 境 变量 

(Environment Variable) ， 在 每 个 Pod 的 容器 里 都 增加 了 一 组 Service 相 

关 的 环境 变量 ， 用 来 记录 从 服务 名 到 虚拟 下 地 址 的 映射 关系 。 以 redis- 
master 服 务 为 例 ， 在 容器 的 环境 变量 中 会 增加 下 面 两 条 记录 : 


REDIS_MASTER_SERVICE_HOST=169.169.144. 74 
REDIS_MASTER_SERVICE_PORT=6379 


于 是 ，redis-slave 和 frontend 等 Pod 中 的 应 用 程序 就 可 以 通过 环境 变 
= REDIS_MASTER_SERVICE_HOST%##] redis-master lu 25 AY KE FU IP Hh, 
址 ， 通 过 环境 变量 REDIS_MASTER_SERVICE_PORT 得 到 redis-master 
服务 的 端口 号 ， 这 样 瓯 完成 了 对 服务 地 址 的 查询 功能 。 


2.3.2 ”创建 redis-slave RC 和 Service 


现在 我 们 已 经 成 功 启 动 了 redis-master 服 务 ， 接 下 来 我 们 继续 完成 
redis-slave 服 务 的 创建 过 程 。 在 本 案例 中 会 启动 redis-slave 服 务 的 两 个 
副本 ， 每 个 副本 上 的 Redis 进 程 都 与 redis-master 进 行 数据 同步 ， 与 redis- 
master 共 同 组 成 了 一 个 具备 读 写 分 离 能 力 的 Redis 集 群 。 留 言 板 的 PHP 
网 页 将 通过 访问 redis-slave 服 务 来 读 取 留 言 数 据 。 与 之 前 的 redis-master 
服务 的 创建 这 程 一 样 ， 首 先 创建 一 个 名 为 redis-slave 的 RC 定义 文件 
redis-slave-controller.yaml， 完 整 内 容 如 下 : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 
template: 
metadata: 
labels: 


name: redis-slave 


spec: 

containers: 

- name: slave 
image: kubeguide/guestbook-redis-slave 
env: 
- name: GET_HOSTS_FROM 

value: env 

ports: 


- containerPort: 6379 


在 容器 的 配置 部 分 设置 了 一 个 环境 变量 
GET HOSTS FROM=env， 意 思 是 从 环境 变量 中 获取 redis-master 服 务 
的 IP 地 址 信息 。 


redis-slave 镜 像 中 的 启动 脚本 /run.sh 的 内 容 为 : 


if [[ ${GET_HOSTS_FROM:-dns} == "env" ]]; then 
redis-server --slaveof $(REDIS MASTER SERVICE HOST] 
6379 
else 
redis-server --slaveof redis-master 6379 


fi 


在 创建 redis-slave Pod 时 ， 系 统 将 上 自动 在 容器 内 部 生成 之 前 已 经 创 
建 好 的 redis-master service 相 关 的 环境 变量 ， 所 以 redis-slave 应 用 程序 
redis-server 可 以 直接 使 用 环境 变量 REDIS_MASTER_SERVICE_HOST 
来 获取 redis-master 服 务 的 IP 地 址 。 


如 果 在 容器 配置 部 分 不 设置 该 senv， 则 将 使 用 redis-master 服 务 的 名 
称 “redis-master 来 访问 它 ， 这 将 使 用 DNS 方式 的 服务 发 现 ， 需 要 预先 
局 动 Kubernetes 集 群 的 skydns 服 务 ， 详 见 2.5.4 市 的 说 明 。 


运行 kubectl create 命 令 : 


$ kubectl create -f redis-slave-controller.yaml 


Replicationcontrollers "redis-slave" created 
运行 kubectl get 命 令 查 看 RC: 


$ kubectl get rc 


NAME DESIRED CURRENT AGE 
redis-master 1 1 1h 
redis-slave 2 2 1h 


查看 RC 创建 的 Pod， 可 以 看 到 有 了 两 个 redis-slave Pod 在 运行 : 


$ kubectl get pods 


NAME READY STATUS 
RESTARTS AGE 

redis-master-bO3io 1/1 Running 0 
1h 

redis-slave-10ahl 1/1 Running 
0 1h 

redis-slave-c5y10 1/1 Running 


0 1h 


然后 创建 redis-slave 服 务 。 类 似 于 redis-master 服 务 ， 与 redis-slave 
相关 的 一 组 环境 变量 也 将 在 后 续 新 建 的 frontend Pod 中 由 系统 目 动 生 
成 o 


配置 文件 redis-slave-service.yaml 的 内 容 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
ports: 
- port: 6379 
selector: 


name: redis-slave 


运行 kubectl 创 建 Service: 


$ kubectl create -f redis-slave-service.yaml 


services/redis-slave 


通过 kubectl 查 看 创建 的 Service: 


$ kubectl get services 
NAME CLUSTER-IP EXTERNAL - IP 
PORT(S) AGE 


frontend 
80/TCP 25m 
redis-master 
25m 
redis-slave 


25m 


169.169.167.153 


169.169.208 .57<none> 


169.169.78.102<none> 


<nodes> 


6379/TCP 


6379/TCP 


2.3.3 创建 frontend RC 和 Service 


类 似 地 ， 定 义 frontend 的 RC 配置 文件 
内 容 如 下 : 


frontend-controller.yaml , 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php-frontend 


env: 


- name: GET HOSTS FROM 
value: env 
ports: 


- containerPort: 80 


在 容器 的 配置 部 分 设置 一 个 环境 变量 
GET HOSTS FROM=env， 意 思 是 从 环境 变量 中 获取 redis-master 和 
redis-slave 服 务 的 IP 地 址 信息 。 


容器 镜像 名 为 kubeguide/guestbook-php-frontend， 该 镜像 中 所 包含 
的 PHP 的 留言 板 源码 (guestbook.php) 如 下 : 


< ? 
set_include_path('.:/usr/local/lib/php'); 
error_reporting(E_ALL); 
ini_set('display_errors', 1); 

require 'Predis/Autoloader.php'; 


PredisNAutoloader::register(); 


if (isset($ GET['cmd']) --- true) ( 
$host - 'redis-master'; 
if (getenv('GET HOSTS FROM') == 'env') { 


$host - getenv('REDIS MASTER SERVICE HOST'); 
} 
header('Content-Type: application/json'); 
if ($ GET['cmd'] == 'set') { 


$client = new Predis\Client([ 


'scheme' => 'tcp', 
'host' => $host, 
'port' -» 6379, 


1); 


$client-»set($ GET['key'], $ GET['value']); 


print('("message": "Updated"}'); 


) else ( 
$host - 'redis-slave'; 
if (getenv('GET HOSTS FROM') == 'env') { 


$host - getenv('REDIS SLAVE SERVICE HOST'); 
} 
$client = new Predis\Client([ 

'scheme' => 'tcp', 

‘host ' => $host, 

'port' => 6379, 
1); 


$value = $client-»get($ GET['key']); 
print('("data": "' , $value . '"}'); 
} 
} else { 
phpinfo(); 


} ? 


这 段 PHP 代 码 的 意思 是 ， 如 果 是 一 个 set 请 求 〈 提 区 留言 ) ， 则 会 
连接 到 redis-master 服 务 进行 写 数据 操作 ， 其 中 redis-master 服 务 的 虚拟 


IP 地 址 是 用 之 前 提 过 的 从 环境 变量 中 获取 的 方式 得 到 的 ， 端 口 使 用 默 
ik 的 6379 端口 号 (当然 ， 也 可 以 使 用 环境 变 
量 "REDIS_MASTER_SERVICE_PORT' 的 值 ) ; 如 果 是 get 请 求 ， 则 会 
连接 到 redis-slave 服 务 进行 读 数据 控 作 。 


可 以 看 到 ， 如 有 果 在 容器 配置 部 分 不 设置 
env“GET_HOSTS_FROM”， 则 将 使 用 redis-master 或 redis-slave 服 务 名 
来 访问 这 两 个 服务 ， 这 将 使 用 DNS 方 式 的 服务 发 现 ， 需 要 预先 启动 
KubemetesS2#¢Askydnsika , VEUL2.5.4 PAPH ° 


运行 kubectl create 命 令 创建 RC: 


$ kubectl create -f frontend-controller.yaml 


replicationcontrollers "frontend" created 


查看 已 创建 的 RC: 


$ kubectl get rc 


NAME DESIRED CURRENT AGE 

frontend 3 3 1h 

redis-master 1 1 1h 

redis-slave 2 2 1h 
再 查看 生成 的 Pod: 


$ kubectl get pods 
NAME READY STATUS 
RESTARTS AGE 


redis-master-b03i0 
0 th 


redis-slave-10ahl 


redis-slave-c5y10 


frontend-4011g 1/1 


1h 


frontend-u9aq6 


frontend-yga1l 1/1 
1h 


1/1 


1/1 


1/1 


1/1 


Running 


Running 


Running 


Running 


Running 


Running 


最 后 创建 frontend Service ， 主 要 目的 是 使 用 Service 的 NodePort 给 
Kubernetes 集 群 中 的 Service 映 射 一 个 外 网 可 以 访问 的 端口 ， 这 样 一 
来 ， 外 部 网 络 就 可 以 通过 NodeIP+NodePort 的 方式 访问 集群 中 的 服务 


[fe 


服务 定义 文件 frontend-service.yaml 的 内 容 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 


spec: 


type: NodePort 

ports: 

- port: 80 
nodePort: 30001 

selector: 


name: frontend 


这 里 的 关键 点 是 设置 type=NodePort 并 指定 一 个 NodePort 的 值 ， 表 
示 使 用 Node 上 的 物理 机 端口 提供 对 外 访问 的 能 力 。 需 要 注意 的 是 ， 
spec.ports.NodePort 的 端口 号 范围 可 以 进行 限制 (通过 kube-apiserver 的 
启动 参数 --service-node-port-range 指 定 ) ， 默 认为 30000~32767， 如 果 
指定 为 可 用 卫 范 围 之 外 的 其 他 问 口 号 ， 则 Service 的 创建 将 会 失败 。 


运行 kubectl create 命 令 创建 Service: 


$ kubectl create -f frontend-service.yaml 


Services "frontend" created 


通过 kubectl 查 看 创建 的 Service: 


$ kubectl get services 
NAME CLUSTER-IP EXTERNAL-IP 


PORT(S) AGE 


frontend 169.169.167.153 <nodes> 
80/TCP 25m 
redis-master 169.169.208.57<none> 


6379/TCP 25m 


redis-slave 169.169.78.102<none> 


6379/TCP 25m 


2.3.4 jJHOCM 88 P] frontend D1 [Hj 
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3 个 应 用 的 6 个 实例 ， 都 运行 在 Kubernetes 集 群 中 。 打 开 浏 览 器 ， 在 地 
址 栏 输 入 http:// 虚 拟 机 IP: 30001/， 将 看 到 如 图 2.6 所 示 的 网 页 ， 并 且 看 
到 网 页 上 有 一 条 留言 一 一 “Hello World! ”。 


Guestbook 


€ > C 192.168.1.130 


Guestbook 


Hello World! 


Al2.6 3B; eae DIR] a A DL 


尝试 输入 一 条 新 的 留言 “Hi Kubemetes! ”， 单 击 Submit 按 钮 ， 网 
页 将 会 在 原 留言 的 oma 留言 ， 说 明 这 文 条 留言 已 已 经 被 成 功 加 入 
Redis 数 据 库 中 了 ， 如 图 2.7 所 示 。 


Guestbook 
€ > C 192.168.1.130 001 


Guestbook 


Hello World! 
Hi Kubernetes! 


图 2.7 ”在 留言 板 网 页 添加 新 的 留言 


通过 Guestbook 示 例 ， 可 以 看 到 Kubernetes 强 大 的 应 用 管理 功能 
用 户 仅 需 通 过 几 个 人 简单 的 YAML 配 置 束 能 完成 复杂 系统 的 搭建 ， 并 能 
够 通过 Kubernetes 目 动 实现 服务 发 现 和 负载 均衡 。 接 下 来 ， 让 我 们 深 
入 Pod 的 应 用 、 配 置 、 调 度 管理 及 服务 的 应 用 ， 开 始 Kubernetes 应 用 管 
理 之 旅 。 


24 ”深入 掌握 Pod 


本 厄 将 对 Kubernetes 如 何 发 布 和 管理 应 用 进行 详细 说 明和 示例 ， 
主要 包括 Pod 和 容器 的 使 用 、Pod 的 控制 和 调度 管理 、 应 用 配置 管理 等 
内 容 。 


2.4.1 ”Pod 定义 详解 


yaml 格 式 的 Pod 定 义 文件 的 完整 内 容 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: string 

namespace: string 

labels: 
- name: string 
annotations: 
- name: string 
spec: 

containers: 

- name: string 
image: string 
imagePullPolicy: [Always | Never | IfNotPresent] 
command: [string] 

args: [string] 
workingDir: string 
volumeMounts: 
- name: string 


mountPath: string 


readOnly: boolean 
ports: 

- name: string 
containerPort: int 
hostPort: int 
protocol: string 

env: 

- name: string 
value: string 

resources: 
limits: 

cpu: string 

memory: string 

requests: 
cpu: string 
memory: string 
livenessProbe: 

exec: 

command: [string] 
httpGet: 

path: string 

port: number 

host: string 

scheme: string 

httpHeaders: 

- name: string 


value: string 


tcpSocket: 
port: number 
initialDelaySeconds: 0 
timeoutSeconds: 0 
periodSeconds: 0 
successThreshold: 0 
failureThreshold: 0 
securityContext: 
privileged: false 
restartPolicy: [Always | Never | OnFailure] 
nodeSelector: object 
imagePullSecrets: 
- name: string 

hostNetwork: false 

volumes: 

- name: string 
emptyDir: {} 
hostPath: 

path: string 
secret: 

secretName: string 

items: 

- key: string 

path: string 

configMap: 

name: string 


items: 


- key: string 


path: string 


对 各 属性 的 详细 说 明 如 表 2.13 所 示 。 
42.13. ”对 Pod 定 义 文件 模板 中 各 属性 的 详细 说 明 


取 值 类 型 | 是 否 必 选 取 值 说 明 


Version String Required 版 本 号 ， 例 如 v1 


kind String Required Pod 


metadata Object Required 元 数据 


metadata.name String Required Pod 的 名 称 ， 命 名 规范 需 符合 RFC 1035 规范 


metadata.namespace String Required Pod 所 属 的 命名 空间 ， 默 认为 “default” 


metadata.labels[] List 定义 标签 列表 


metadata.annotation[] List 自 定义 注解 列表 


Spec Object Required Pod 中 容器 的 详细 定义 


spec.containers[] List Required Pod 中 的 容器 列表 


spec.containers[].name String Required 容器 的 名 称 ， 需 符合 RFC 1035 规范 


spec.containers[].image String Required 容器 的 镜像 名 称 


续 表 
属性 名 称 取 值 类 型 | 是 否 必 选 Hk 值 说 明 


spec.containers[] imagePullPolicy Sting 获取 镜像 的 策略 ， 可 选 值 包括: Always. Never. 
INotPresent, WURA Always. 
Always: 表示 每 次 都 尝试 重新 下 载 镜像 。 
IfNotPresent 表示 如 果 本 地 有 该 镜像 ， 则 使 用 本 
地 的 镜像 ， 本 地 不 存在 时 下 载 镜 像 。 
Never: 表示 仅 使 用 本 地 镜像 


pu cro m 
打包 时 使 用 的 启动 fe 

[pee continents tit | erations E o | 
[pec containers workineDir | Sein | |S8 的 TfH 录 | 


-peccontmervolimeMowns(} (ne [ — — efeememcutem | 

——— T 
volumes Sf 3% (HE T 

Se A | qam 
个 字符 


| eecenpiner0vehmeMountllreaaoat [Boolean |  [ESARRRR, RUAA 


m —— QU [ BHEZERRASDUAR 
|speccontsiners{}port[Jname Sting — | marae 
spec.containers[].ports[].containerPort |spec.containers{},ports[J.containerPort — |l | | 容器 需要 监听 的 端口 号 


spec.containers[].ports[J-hostPort 容器 所 在 主机 需要 装 听 的 端口 号 ,默认 与 
containerPort 相同 。 设 置 hostPort 时 ， 同 一 台 宿 主 
机 将 无 法 启动 该 容器 的 第 2 份 副本 


[5ps containers ports} protocol Swing || HNL, 支持 TCP 和 UDP， RUA TCP 
|sesmmmeüenü tt || rai iON mns 
beee a 于 二 环境 变量 的 名 称 


spec.containers[].resources limits memory 


EES 


CPU 请 求 ， 单 位 为 core 数 ， 容 器 启动 的 初始 可 用 
数量 
em | 内 存 请 求 ， 单 位 可 以 为 MiB、GiB 等 ， 容 器 启动 
的 初始 可 用 数量 
在 该 Pod 上 定义 的 共享 存储 卷 列表 
volumes[]. 
volume: [] lix 


类 型 为 emptyDir 的 存储 卷 , AAG Pod 同 生命 周期 
的 一 个 临时 目录 ,其 值 为 一 个 空 对 象 : emptyDir {} 
类 型 为 hostPath 的 存储 着， 表示 挂 载 Pod 所 在 宿 
主机 的 目录 ， 通 过 volumes[]. hostPath path 指定 
Pod 所 在 主机 的 目录 ， 将 被 用 于 容器 中 mount 的 
目录 

类 型 为 secret 的 存 鳍 着， 表示 挂 载 集 群 预 定义 的 
secret 对 象 到 容器 内 部 

类 型 为 confisMap 的 存储 谷 ， 表 示 挂 载 集群 预定 
义 的 con&gMap 对 和 象 到 容器 内 部 

对 Pod 内 各 容器 健康 检查 的 设置 ， 当 探测 无 响应 
几 次 之 后 ， 系 统 将 自动 重启 该 容器 。 可 以 设置 的 
方法 包括 : exec. httpGet 和 tcpSocket。 对 一 个 容 
器 仅 需 设置 一 种 健康 检查 方法 


X Pod 内 各 容器 健康 检查 的 设置 ，exec 方式 
exec 方式 需要 指定 的 命令 或 者 脚本 


RY Pod 内 各 容器 健康 检查 的 设置 , HTTPGet 方式 。 
MIRJE path. port 


spec.volumes[].emptyDir 


Ld 
FEEL ZH, 4E— i Pod 中 每 个 存储 卷 定 
义 一 个 名 称 ， 应 符合 RFC 1035 规范 。 容器 定义 部 
分 的 contamer:[]volumeMount:[]name 将 引用 该 
共享 存 鳍 卷 的 名 称 ， 
volume 的 类 型 包括 : emptyDir. hostPath 、 
geePersistentDisk, awsElasticBlockStore. gitRepo. 
secret, nfs, iscsi, glusterfs , persistentVolumeClaim. 
rbd , flexVolume , cinder, cephfs , flocker 、 
downwardAPI . fc . azureFile 、 configMap 、 
vsphereVolume, EJU SE X £^ volume. fH 
volume 的 name 保持 叭 一 。 本 节 讲 解 emptyDir. 
hostPath、secret、confisMap it 4 种 volume， 其 他 
FM volume 的 设置 方式 详 见 第 1 章 的 说 图 

| 

| 

| 

| 


| 


spec.volumes[].configMap 


spec silumes[Llsceness Pile ai 
Ouest — | 
Swing — | 


|:pecsohmer]lenesProbeereccommamd] | Sting 


spec.volume:[] livenessProbe httpGet -- 


[] resources requests.cpu 
[]. resources requests.me: 
1venessProbe.exec.command[] 


续 表 
属性 名 称 取 值 类 型 | 是 否 必 选 取 值 说 明 


spec Volumes[] livenessProbe tcpSocket Object 对 Pod 内 各 容器 健康 检查 的 设置 ，tcpSocket 方式 
spec. volumes[] livenessProbe initialDelaySeconds | Number 容器 启动 完成 后 进行 首次 探测 的 时 间 ， 单 位 为 秒 
spec.volumes[] .livenessProbe timeoutSeconds |N 对 容器 健康 检查 的 探测 等 待 响应 的 超时 时 间 设 


置 ， 单 位 为 秒 ， 默 认为 1 秒 。 超 过 该 超时 时 间 设 


置 ， 将 认为 该 容器 不 健康 ， 将 重启 该 容器 
对 容器 健康 检查 的 定期 探测 时 间 设 置 ， 单位 为 秒 ， 
默认 为 10 秒 探测 一 次 


设置 NodeSelector 表示 将 该 Pod 调度 到 包含 这 些 
label 的 Node 上 ， 以 key-value 格式 指定 

Pull 镜像 时 使 用 的 secret 名 称 ， 以 name:secretkey 
格式 指定 

是 否 使 用 主机 网 络 模式 ， 默 认为 false。 如 果 设 置 
为 true, Wc mM 不 再 使 用 
Docker 网 桥 ， 该 Pod 将 无 法 在 同一 台 宿 主机 上 启 
动 第 2 个 副本 


spec.nodeSelector Object 
spec.imagePullSecrets Object 


spec.hostNetwork 


spec restartPolicy Pod 的 重启 策略 ， 可 选 值 为 Always、OnFailure， 
默认 值 为 Always。 
Always: Pod 一 旦 终止 运行 , 则 无 论 容器 是 如 何 终 
止 的 ，kubelet 都 将 重启 它 。 
OnFailure: 只 有 Pod 以 非 零 退 出 码 终 止 时 , kubelet 
才 会 重启 该 容器 。 如 果 容 器 正常 结束 (退出 码 为 
0)， 则 kubelet 将 不 会 重启 它 。 
Never: Pod 终止 后 ，kubelet 将 退出 码 报告 给 
Master， 不 会 再 重启 该 Pod 


2.4.2 ”Pod 的 基本 用 法 


在 对 pod 的 用 法 进行 说 明之 前 ， 有 必要 先 对 Docker 容 器 中 应 用 的 运 
行 要 求 进行 说 明 。 


在 使 用 Docker 时 ， 可 以 使 用 docker run 命 令 创建 并 启动 一 个 容器 。 
而 在 Kubernetes 系 统 中 对 长 时 间 运 行 容 句 的 要 求 是 ， 其 主 程序 需要 一 
直 在 前 台 执 行 。 如 果 我 们 创建 的 Docker 镜 像 的 启动 命令 是 后 台 执 行程 
序 ， 例 如 Linux 脚 本 : 


nohup ./start.sh & 


则 在 kubelet 创 建 包含 这 个 容器 的 Pod 之 后 运行 完 该 命令 ， 即 认为 
Pod 执行 结束 ， 将 立刻 销毁 该 Pod。 如 果 为 该 Pod 定 义 了 
ReplicationController, ， 则 系统 将 会 监控 到 该 Pod 已 经 终止 ， 之 后 根据 
RC 定 义 中 Pod 的 replicas 副 本 数量 生成 一 个 新 的 Pod。 而 一 旦 创建 出 新 
的 Pod， 就 将 在 执行 完 启 动 命令 后 ， 陷 入 无 限 循 环 的 过 程 中 。 这 就 是 
Kubernetes 需 要 我 们 目 己 创建 的 Docker 镜 像 以 一 个 前 台 命 令 作为 启动 命 
令 的 原因 。 


对 于 无 法 改造 为 前 台 执 行 的 应 用 ， 也 可 以 使 用 开源 工具 Supervisor 
辅助 进行 前 台 运 行 的 功能 。Supervisor 提 供 了 一 种 可 以 同时 启动 多 个 后 
人 台 应 用 ， 并 保持 Supervisor 目 身 在 前 台 执 行 的 机 制 ， 可 以 满足 
Kubernetes 对 容器 的 启动 要 求 。 关 于 Supervisor 的 安装 和 使 用 ， 请 参考 
官网 http://supervisord.org 的 文档 说 明 。 


a 的 封装 和 应 用 进行 说 明 ，Pod 的 基本 用 法 为 : 
Pod 可 以 由 1 个 或 多 个 容器 组 合 而 成 。 


在 上 一 节 Guestbook 的 例子 中 ， 名 为 frontend 的 Pod 只 由 一 个 容 絮 组 
成 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php-frontend 
env: 
- name: GET_HOSTS_FROM 
value: env 
ports: 


- containerPort: 80 


这 个 frontendPod 在 成 功 启 动 之 后 ， 将 启动 1 个 Docker 容 器 。 


男 一 种 场景 是 ， 当 frontend 和 redis 两 个 容器 应 用 为 紧 厦 合 的 天 系 ， 
应 该 组 合成 一 个 整体 对 外 提供 服务 时 ， 则 应 将 这 两 个 容器 打包 为 一 个 
Pod， 如 图 2.8 所 示 。 


Pod 


$F dir CF tit 


frontend redis-master 
:80 localhost:6379 
localhost 


图 2.8 ”包含 两 个 容器 的 Pod 
配置 文件 frontend-localredis-pod.yaml 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: redis-php 

labels: 

name: redis-php 

spec: 

containers: 

- name: frontend 


image: kubeguide/guestbook-php-frontend:localredis 


ports: 
- containerPort: 80 
- name: redis 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


qo ed 88 NL FB Z RETE EL V RISE 1 3X localhost 
就 可 以 通信 ， 使 得 这 容器 被 * 绑 定 ” 人 在 了 一 个 环境 中 。 


JE Docker 4% # kubeguide/guestbook-php-frontend: localredis 的 PHP 
网 页 中 ， 直 接 通 过 UREL 地 址 "localhost: 6379” 对 同属 于 一 个 Pod 内 的 
redis-masterj 进 行 访问 。guestbook.php 的 内 容 如 下 : 


< ? 
set_include_path('.:/usr/local/lib/php'); 
error reporting(E ALL); 

ini set('display errors', 1); 

require 'Predis/Autoloader.php'; 


PredisNAutoloader::register(); 


if (isset($ GET['cmd']) === true) { 
$host - 'localhost'; 
Af (getenv('REDIS HOST') && 
strlen(getenv('REDIS HOST')) > 0) ( 


$host - getenv('REDIS HOST'); 


header('Content-Type: application/json'); 
if ($ GET['cmd'] == 'set') { 
$client = new Predis\Client([ 
'scheme' => 'tcp', 
"host ' => $host, 
'port' -» 6379, 
1); 


$client->set($_GET['key'], $ GET['value']); 
print('("message": "Updated"}'); 
) else ( 
$host - 'localhost'; 
if (getenv('REDIS HOST') 
strlen(getenv('REDIS HOST')) > 0 ) ( 
$host = getenv('REDIS HOST'); 
} 
$client = new Predis\Client([ 
'scheme' => 'tcp', 
‘host ' => $host, 
'port' => 6379, 
1); 


$value = $client-»get($ GET['key']); 
print('{"data": "' . $value . '"}'); 


} 
} else { 


&& 


phpinfo(); 


Mae 


运行 kubectl create 命 令 创建 该 Pod: 


$ kubectl create -f frontend-localredis-pod.yaml 


pod "redis-php" created 


查看 已 创建 的 Pod: 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


redis-php 2/2 Running 0 10m 


可 以 看 到 READY 信 息 为 222， 表 示 Pod 中 的 两 个 容器 都 成 功 运 行 
ap. o 


查看 这 个 Pod 的 详细 信息 ， 可 以 看 到 两 个 容器 的 定义 及 创建 的 过 
程 (Event 事 件 信 息 ) 


# kubectl describe pod redis-php 


Name: redis-php 

Namespace: default 

Node: k8s/192.168.18.3 

Start Time: Thu, 28 Jul 2016 12:28:21 +0800 
Labels: name=redis - php 

Status: Running 


IP: 172.17.1.4 


Controllers: <none> 
Containers: 
frontend: 

Container ID: 
docker://ccc8616f 8dfifbi9abbd0ab189a36e6f6628b78ba7b97b1077 
d86e7fc224ee08 

Image: kubeguide/guestbook- 
php-frontend:localredis 
Image ID: 
docker://sha256:d014f67384a11186e135b95a7ed0d794674f7ce258f 
0dce47267c3052a0d0fa9 
Port: 80/TCP 
State: Running 
Started: Thu, 28 Jul 2016 
12:28:22 +0800 


Ready: True 

Restart Count: 0 

Environment Variables: <none> 
redis: 


Container ID: 
docker ://c0b19362097cda6dd5b8ed7d8eaaaf 43aeeb969ee023ef 2556 
04bde089808075 
Image: kubeguide/redis-master 
Image ID: 
docker://sha256:405a0b586f 7ebeb545ec65be0e914311159d1baedcc 
d3a93e9d3e3b249ec5cbd 


Port: 6379/TCP 


State: Running 
Started: Thu, 28 Jul 2016 
12:28:23 +0800 


Ready: True 
Restart Count: 0 
Environment Variables: <none> 
Conditions: 
Type Status 


Initialized True 

Ready True 

PodScheduled True 
Volumes: 


default-token-97j21: 


Type: Secret (a volume populated by a 
Secret) 
SecretName: default-token-97j21 
QoS Tier: BestEffort 
Events: 
FirstSeen LastSeen Count From SubobjectPath 


Type Reason Message 


18m18m 1 (default-scheduler } 
Normal Scheduled Successfully assigned redis- 
php to k8s-node-1 

18m18m 1 {kubelet k8s-node-1} 


spec.containers{frontend} Normal Pulled 


Container image "kubeguide/guestbook-php- 
frontend:localredis" already present on machine 

18m18m 1 {kubelet k8s-node-1} 
spec.containers{frontend} Normal Created 
Created container with docker id ccc8616f8df1 

18mi8m 1 {kubelet k8s-node-1} 
spec.containers{frontend} Normal Started 
Started container with docker id ccc8616f8df1 

18mi8m 1 {kubelet k8s-node-1} 
spec.containers{redis } Normal Pulled 


Container image "kubeguide/redis-master" already present on 


machine 
18mi8m 1 {kubelet k8s-node-1} 
spec.containers{redis } Normal Created 


Created container with docker id c0b19362097c 
18m18m 1 {kubelet k8s-node-1} 
spec.containers{redis } Normal Started 


Started container with docker id c0b19362097c 


2.4.3 PA Pod 


静态 Pod 是 由 kubelet 进 行 管理 的 仅 存在 于 特定 Node 上 的 Pod。 它 们 
不 能 通过 API Server 进行 管理 ， 无 法 与 ReplicationController ^ 
Deployment2Y zt DaemonSetii íT KEK, Jf H kubelet th IEW EA ET 
ERRA ° HRASPod Se Hkubeletitt 47 fl, Jf Ake TEkubeletPTTERS 
Node E3517 ° 


创建 静态 Pod 有 两 种 方式 ， 配 置 文件 或 者 HTTP 方 式 。 


1) 配置 文件 方式 


首先 ， 需 要 设置 kubelet 的 启动 参数 “--config”， 指 定 kubelet 需 要 监 
控 的 配置 文件 所 在 的 目录 ，kubelet 会 定期 扫描 该 目录 ， 并 根据 该 目录 
中 的 .yaml 或 .json 文 件 进行 创建 操作 。 


假设 配置 目录 为 /etc/kubelet.d/ ， 配 置 启动 参数 : -- 
config=/etc/kubelet.d/， 然 后 重启 kubelet 服 务 。 


在 目录 /etc/kubelet.d 中 放 入 static-web.yaml 文 件 ， 内 容 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 

name: static-web 


labels: 


name: static-web 
spec: 

containers: 

- name: static-web 
image: nginx 
ports: 

- name: web 


containerPort: 80 


PA 


SERIAL. BAAS CARN Ae: 


# docker ps 
CONTAINER ID IMAGE COMMAND CREATED STATUS 
PORTS NAMES 
2292ea231ab1 nginx "nginx -g ‘daemon off" 1 
minute ago im k8s static-web.68ee0075 static-web-k8s- 


node-1 default 78c7efddebfi191c949cbb7aa22a927c8 401b96d0 


可 以 看 到 一 个 Nginx 容 器 已 经 被 kubelet 成 功 创建 了 出 来 。 


到 Master 节 点 查看 Pod 列 表 ， 可 以 看 到 这 个 static pod: 


# kubectl get pods 
NAME READY STATUS 


RESTARTS AGE 


static-web-nodei 1/1 Running 0 


5m 


由 于 静态 Pod 无 法 通过 API Server ‘es YR, Hr AE Master P A E 
试 删 除 这 个 Pod， 将 会 使 其 变 成 Panding 状 态 ， 且 不 会 被 删除 。 


# kubectl delete pod static-web-node1 


pod "static-web-nodei" deleted 


# kubectl get pods 


NAME READY STATUS RESTARTS 
AGE 


static-web-node1 0/1 Pending 0 


1s 


删除 该 Pod 的 操作 只 能 是 到 其 所 在 Node 上 ， 将 其 定义 文件 static- 
web.yaml 从 /etc/kubelet.d 目 好 下 删除 。 


# rm /etc/kubelet.d/static-web.yaml 
# docker ps 


// 无 容器 正在 运行 。 


F~ AA 


244 Pod 7ett= Volume 


在 同一 个 Pod 中 的 多 个 容器 能 够 共 译 Pod 级 别 的 存储 卷 Volume 。 
Volume 可 以 定义 为 各 种 类 型 ， 多 个 容器 各 目 进 行 挂 载 操 作 ， 将 一 个 
Volume 挂 载 为 容 右 内 部 需要 的 目录 ， 如 图 2.9 所 示 。 


Pod 


ain ids 
tomcat busvbox 


图 2.9 Pod 中 多 个 容器 共享 volume 


在 下 面 的 例子 中 ，Pod 内 包含 两 个 容 右 : tomcat 和 busybox， 在 Pod 
级 别 设置 Volume“app-logs”， 用 于 tomcat 同 其 中 写 日 志文 件 ，busybox 读 
日 志文 件 。 


配置 文件 pod-volume-applogs.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: volume-pod 
spec: 
containers: 
- name: tomcat 
image: tomcat 
ports: 
- containerPort: 8080 
volumeMounts: 
- name: app-logs 
mountPath: /usr/local/tomcat/logs 
- name: busybox 
image: busybox 
command: sh"; ep. "tail 
/logs/catalina*.log"] 
volumeMounts: 
- name: app-logs 
mountPath: /logs 
volumes: 
- name: app-logs 


emptyDir: {} 


这 里 设置 的 Volume 名 为 app-logs， 类 型 为 emptyDir (也 可 以 设置 为 
其 他 类 型 ， 详 见 第 1 章 对 Volume 概 念 的 说 明 ) ， 挂 载 到 tomcat 容 器 内 
的 /usvlocalMtomcatlogs 目 未 ， 同 时 挂 载 到 logreader 容 需 内 的 /logs 目 未 。 
tomcat 4 zs 4 JAB) Ja 2: [A] /usr/local/tomcat/logs H 5€ F 5j X. fft, logreader 
容器 就 可 以 读 取 其 中 的 文件 了 。 


logreader 容 屁 的 启动 命令 为 tail-f/logs/catalina*.log， 我 们 可 以 通过 
kubectl logs 命 令 查 看 logreader 容 器 的 输出 内 容 : 


# kubectl logs volume-pod -c busybox 
29-Jul-2016 12:55:59.626 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDirectory 
Deploying web application directory 
/usr/local/tomcat/webapps/manager 
29-Jul-2016 12:55:59.722 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDirectory 
Deployment of web application directory 
/usr/local/tomcat/webapps/manager has finished in 96 ms 
29-Jul-2016 12:55:59.740 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["http-apr-8080" ] 
29-Jul-2016 12:55:59.794 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["ajp-apr-8009" ] 
29-Jul-2016 12:56:00.604 INFO [main] 


org.apache.catalina.startup.Catalina.start Server startup 


in 4052 ms 


这 个 文件 即 为 tomcat 生 成 的 日 志文 件 /usr/local/tomcat/logs/catalina. 
<date>.logh AZ ° sxtomcat art {THA : 


# kubectl exec -ti volume-pod -c tomcat -- Ils 
/usr/local/tomcat/logs 
catalina.2016-07-29.10g 
localhost access 1log.2016-07-29.txt 


host-manager.2016-07-29.10g manager.2016-07-29.10g 


# kubectl exec -ti volume-pod -c tomcat -- tail 
/usr/local/tomcat/logs/catalina.2016-07-29.10g 
29-Jul-2016 12:55:59.722 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployDirectory 
Deployment of web application directory 
/usr/local/tomcat/webapps/manager has finished in 96 ms 
29-Jul-2016 12:55:59.740 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["http-apr-8080" ] 
29-Jul-2016 12:55:59.794 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["ajp-apr-8009" ] 
29-Jul-2016 12:56:00.604 INFO [main] 


org.apache.catalina.startup.Catalina.start Server startup 


in 4052 ms 


2.4.5 “Pod 的 配置 管理 


应 用 部 署 的 一 个 最 佳 实践 是 将 应 用 所 需 的 配置 信息 与 程序 进行 分 
离 ， 这 样 可 以 使 得 应 用 程序 被 更 好 地 复 用 ， 通 过 不 同 的 配置 也 能 实现 
更 灵活 的 功能 。 将 应 用 打包 为 容器 镜像 后 ， 可 以 通过 环境 变量 或 者 外 
挂 文 件 的 方式 在 创建 容器 时 进行 配置 注入 ， 但 在 大 规模 容 絮 集群 的 环 
境 中 ， 对 多 个 容器 进行 不 同 的 配置 将 变 得 非常 复杂 。Kubernetesv1.2 版 
本 提供 了 一 种 统一 的 集群 配置 管理 方案 ConfigMap。 本 方 对 
ConfigMap 的 概念 和 用 法 进行 详细 描述 。 


1.ConfigMap: 容 右 应 用 的 配置 管理 

ConfigMap 供 容器 使 用 的 典型 用 法 如 下 。 
(1) 生成 为 容器 内 的 环境 变量 。 
(2) 设置 容器 启动 命令 的 启动 参数 ( 需 设 置 为 环境 变量 ) 。 
(3) 以 Volume 的 形式 挂 载 为 容器 内 部 的 文件 或 目录 。 


ConfigMap 以 一 个 或 多 个 key: value 的 形式 保存 在 Kubernetes 系 统 
中 供应 用 使 用 ， 既 可 以 用 于 表示 一 个 变量 的 值 (例如 
apploglevel=info) ， 也 可 以 用 于 表示 一 个 完整 配置 文件 的 内 容 (例如 


server.xml-«? xml...>...) 


可 以 通过 yaml 配 置 文件 或 者 直接 使 用 kubectl create configmap fii > 
行 的 方式 来 创建 ConfigMap 。 


2.ConfigMap 的 创建 : yaml 文 件 方式 


下 面 的 例子 cm-appvars.yaml 描 述 了 将 几 个 应 用 所 需 的 变量 定义 为 
ConfigMap 的 用 法 : 


cm-appvars.yaml 
apiVersion: vi 
kind: ConfigMap 
metadata: 
name: cm-appvars 
data: 
apploglevel: info 
appdatadir: /var/data 


执行 kubectl create fit 4 ll 1% ConfigMap: 


$kubectl create -f cm-appvars.yaml 


configmap "cm-appvars" created 


查看 创建 好 的 ConfigMap: 


# kubectl get configmap 
NAME DATA AGE 


cm-appvars 2 3S 


# kubectl describe configmap cm-appvars 


Name: cm-appvars 
Namespace: default 
Labels: «none» 
Annotations: «none» 
Data 

appdatadir: 9 bytes 
apploglevel: 4 bytes 


# kubectl get configmap cm-appvars -o yaml 
apiVersion: vi 
data: 
appdatadir: /var/data 
apploglevel: info 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-07-28T19:57:16Z 
name: cm-appvars 
namespace: default 
resourceVersion: "78709" 
selfLink: /api/vi/namespaces/default/configmaps/cm- 
appvars 


uid: 7bb2e9c0-54fd-11e6-9dcd-000c29dc2102 


下 面 的 例子 cm-appconfigfiles.yaml 描 述 了 将 两 个 配置 文件 
serverxml 和 1logging.properties 定 义 为 ConfigMap 的 用 法 ， 设 置 key 为 配 
置 文件 的 别名 ，value 则 是 配置 文件 的 全 部 文本 内 容 : 


cm-appconfigfiles.yaml 

apiVersion: vi 

kind: ConfigMap 

metadata: 

name: cm-appconfigfiles 
data: 
key-serverxml: | 
< xml version='1.0' encoding-'utf-8' > 
<Server port="8005" shutdown="SHUTDOWN"> 
<Listener 
className="org.apache.catalina.startup.VersionLoggerListene 
r" /> 
<Listener 

className="org.apache.catalina.core.AprLifecycleListener" 
SSLEngine="on" /> 

<Listener className= 
"org.apache.catalina.core.JreMemoryLeakPreventionListener" 
/> 

<Listener className= 
"org.apache.catalina.mbeans.GlobalResourcesLifecycleListene 
r" /> 

<Listener className= 


"org.apache.catalina.core.ThreadLocalLeakPreventionListener 


" /> 
<GlobalNamingResources> 


<Resource name="UserDatabase" auth="Container" 


type-"org.apache.catalina.UserDatabase" 


description="User database that can 


be updated and saved" 


factory="org.apache.catalina.users.MemoryUserDatabaseFactor 


y 


pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 
<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 
<Connector port="8009" protocol="AJP/1.3" 
redirectPort="8443" /> 
«Engine name="Catalina" defaultHost="localhost"> 
<Realm 
className="org.apache.catalina.realm.LockOutRealm"> 
<Realm 
className="org.apache.catalina.realm.UserDatabaseRealm" 
resourceName="UserDatabase"/> 
</Realm> 


<Host name="localhost" appBase="webapps" 


unpackWARs="true" autoDeploy="true"> 
<Valve 
className="org.apache.catalina.valves.AccessLogValve" 
directory="logs" 
prefix-"localhost access log" 
suffix=".txt" 
pattern="%h %1 %u %t &quot;%r&quot; 
%S 9b" /> 


</Host> 
</Engine> 
</Service> 
</Server> 
key-loggingproperties: "handlers 
-1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, 
3manager.org.apache.juli.FileHandler, 4host- 
manager.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler\r\n\r\n.handlers= 


1catalina.org.apache.juli.FileHandler, 


java.util.logging.ConsoleHandler\r\n\r\nicatalina.org.apach 


e.juli.FileHandler.level 


FINE\r\nicatalina.org.apache. juli.FileHandler.directory = 
${catalina.base}/logs\r\nicatalina.org.apache. juli.FileHand 


ler.prefix 


catalina. \r\n\r\n2localhost.org.apache. juli.FileHandler.lev 
el = 


FINE\r\n2localhost.org.apache. juli.FileHandler.directory 


${catalina.base}/logs\r\n2localhost.org.apache. juli.FileHan 
dler.prefix = 
localhost.\r\n\r\n3manager.org.apache. juli.FileHandler.leve 


1 


FINENrNn3manager.org.apache.juli.FileHandler.directory - 
${catalina.base}/logs\r\n3manager.org.apache. juli.FileHandl 
er.prefix 
= manager. \r\n\r\n4host - 
manager .org.apache. juli.FileHandler.level = FINE\r\n4host- 
manager .org.apache. juli.FileHandler.directory 
= ${catalina.base}/logs\r\n4host- 
manager .org.apache. juli.FileHandler.prefix = 
host- 
manager.NrNnNrNnjava.util.logging.ConsoleHandler.level - 


FINE\r\njava.util.logging.ConsoleHandler.formatter 


java.util.logging.SimpleFormatter\r\n\r\n\r\norg.apache.cat 
alina.core.ContainerBase.[Catalina].[localhost].level 
= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina]. [localhost].handlers 


2localhost.org.apache. juli.FileHandler\r\n\r\norg.apache.ca 
talina.core.ContainerBase.[Catalina].[localhost]. 
[/manager].level 

= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina]. [localhost].[/manager].handlers 


3manager.org.apache. juli.FileHandler\r\n\r\norg.apache.cata 
lina.core.ContainerBase. [Catalina].[localhost].[/host- 
manager |.level 
= INFO\r\norg.apache.catalina.core.ContainerBase. 
[Catalina] .[localhost].[/host-manager ].handlers 
= 4host - 


manager .org.apache. juli.FileHandler\r\n\r\n" 


执行 kubectl create 命 令 创建 该 ConfigMap: 


$kubectl create -f cm-appconfigfiles.yaml 


configmap "cm-appconfigfiles" created 


查看 创建 好 的 ConfigMap: 


# kubectl get configmap cm-appconfigfiles 
NAME DATA AGE 


cm-appconfigfiles 2 14s 


# kubectl describe configmap cm-appconfigfiles 


Name: cm-appconfigfiles 


Namespace: default 


Labels: <none> 
Annotations: <none> 
Data 


key-loggingproperties: 1809 bytes 


key-serverxml: 1686 bytes 


查看 已 创建 的 ConfigMap 的 详细 内 容 ， 可 以 看 到 两 个 配置 文件 的 


EM: 


# kubectl get configmap cm-appconfigfiles -o yaml 
apiVersion: v1 
data: 
key-loggingproperties: "handlers = 
1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, 
3manager.org.apache.juli.FileHandler, 4host- 
manager.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler\r\n\r\n.handlers 


= 1catalina.org.apache.juli.FileHandler, 


java.util.logging.ConsoleHandler\r\n\r\nicatalina.org.apach 


e.juli.FileHandler.level 


FINE\r\nicatalina.org.apache. juli.FileHandler.directory = 


${catalina.base}/logs\r\nicatalina.org.apache. juli.FileHand 


ler.prefix 


catalina.\r\n\r\n2localhost.org.apache.juli.FileHandler.lev 
el = 


FINE\r\n2localhost.org.apache. juli.FileHandler.directory 


${catalina.base}/logs\r\n2localhost.org.apache. juli.FileHan 
dler.prefix = 
localhost.\r\n\r\n3manager.org.apache. juli.FileHandler.leve 


1 


FINENrNn3manager.org.apache.juli.FileHandler.directory - 
${catalina.base}/logs\r\n3manager.org.apache. juli.FileHandl 
er.prefix 
- manager. \r\n\r\n4host - 
manager .org.apache.juli.FileHandler.level = FINE\r\n4host- 
manager .org.apache. juli.FileHandler.directory 
= ${catalina.base}/logs\r\n4host- 
manager .org.apache. juli.FileHandler.prefix = 
host - 
manager. \r\n\r\njava.util.logging.ConsoleHandler.level = 


FINE\r\njava.util.logging.ConsoleHandler.formatter 


java.util.logging.SimpleFormatter\r\n\r\n\r\norg.apache.cat 
alina.core.ContainerBase.[Catalina].[localhost].level 


= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina]. [localhost].handlers 


2localhost.org.apache. juli.FileHandler\r\n\r\norg.apache.ca 
talina.core.ContainerBase.[Catalina].[localhost]. 
[/manager].level 

= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina].[localhost].[/manager].handlers 


3manager.org.apache.juli.FileHandlerNrNnNrNnorg.apache.cata 
lina.core.ContainerBase.[Catalina].[localhost].[/host- 
manager].level 

= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina].[localhost].[/host-manager ].handlers 


= Ahost- 
manager .org.apache. juli.FileHandler\r\n\r\n" 
key-serverxml: | 
< xml version='1.0' encoding='utf-8' > 
<Server port="8005" shutdown="SHUTDOWN"> 
<Listener 


className="org.apache.catalina.startup.VersionLoggerListene 
r" /> 

«Listener 
className="org.apache.catalina.core.AprLifecycleListener" 
SSLEngine="on" /> 

<Listener 
className="org.apache.catalina.core. JreMemoryLeakPrevention 


Listener" /> 


<Listener 
className="org.apache.catalina.mbeans.GlobalResourcesLifecy 
cleListener" /> 
<Listener 
className="org.apache.catalina.core.ThreadLocalLeakPreventi 
onListener" /> 
<GlobalNamingResources> 


<Resource name="UserDatabase" auth="Container" 


type="org.apache.catalina.UserDatabase" 
description="User database that can 


be updated and saved" 


factory="org.apache.catalina.users.MemoryUserDatabaseFactor 


y 


pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 
<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 
<Connector port="8009" protocol="AJP/1.3" 
redirectPort="8443" /> 
«Engine name="Catalina" defaultHost="localhost"> 
<Realm 


className="org.apache.catalina.realm.LockOutRealm"> 


<Realm 
className="org.apache.catalina.realm.UserDatabaseRealm" 
resourceName="UserDatabase"/> 
</Realm> 
«Host name="localhost" appBase="webapps" 
unpackWARs="true" autoDeploy="true"> 
<Valve 
className="org.apache.catalina.valves.AccessLogValve" 
directory="logs" 
prefix="localhost_access_log" 
suffix=".txt" 
pattern="%h %1 %u %t &quot;%r&quot; 


%S 96b" /> 


</Host> 
</Engine> 
</Service> 
</Server> 
kind: ConfigMap 
metadata: 
creationTimestamp: 2016-07-29T00:52:18Z 
name: cm-appconfigfiles 
namespace: default 
resourceVersion: "85054" 
selfLink: /api/vi/namespaces/default/configmaps/cm- 
appconfigfiles 
uid: b30d5019-5526-11e6-9dcd-000c29dc2102 


3.ConfigMapH GI: kubectl 命 令 行 方式 


不 使 用 yaml 文 件 ， 直 接 通过 kubect create configmap 也 可 以 创建 
ConfigMap， 可 以 使 用 参数 --from-file 或 --from-literal 指 定 内 容 ， 并 且 可 
以 在 一 行 命令 中 指定 多 个 参数 。 


(1) 通过 --from-file 参 数 从 文件 中 进行 创建 ， 可 以 指定 key 的 名 
称 ， 也 可 以 在 一 个 命令 行 中 创建 包含 多 个 key 的 ConfigMap， 语 法 为 : 


# kubectl create configmap NAME --from-file= 


[key=]source --from-file=[key=]source 


(2) 通过 --from-file 参 数 从 目录 中 进行 创建 ， 该 目录 下 的 每 个 配 
置 文 件 名 都 被 设置 为 key， 文 件 的 内 容 被 设置 为 value， 语 法 为 : 


# kubectl create configmap NAME --from-file=config- 


files-dir 


(3) --from-literal 从 文本 中 进行 创建 ， 直 接 将 指定 的 key#=value# 
创建 为 ConfigMap 的 内 容 ， 语 法 为 : 


#  kubectl create  configmap NAME --from- 


literal-keyi-valuei --from-literal-key2-value2 


下 面 对 这 儿 种 用 法 举例 说 明 。 


例如 ， 当 前 目 孙 下 含有 配置 文件 serverxml， 可 以 创建 一 个 包含 该 
文件 内 容 的 ConfigMap: 


# kubectl create configmap cm-server.xml --from- 
file=server.xml 


configmap "cm-server.xml" created 


# kubectl describe configmap cm-server.xml 


Name : cm-server.xml 
Namespace: default 
Labels: «none» 
Annotations: «none» 

Data 

server.xml: 6458 bytes 


假设 configfiles H 3 F € & WW ^ Bc E X fF server.xml 和 
logging.properties， 创 建 一 个 包含 这 两 个 文件 内 容 的 ConfigMap: 


# kubectl create configmap cm-appconf  --from- 
file-configfiles 


configmap "cm-appconf" created 


# kubectl describe configmap cm-appconf 
Name: cm-appconf 


Namespace: default 


Labels: <none> 


Annotations: <none> 

Data 

logging.properties: 3354 bytes 
server.xml: 6458 bytes 


使 用 --from-literal 参 数 进行 创建 的 示例 如 下 : 


# kubectl create configmap cm-appenv --from- 
literal=loglevel=info --from-literal=appdatadir=/var/data 


configmap "cm-appenv" created 


# kubectl describe configmap cm-appenv 


Name: cm-appenv 
Namespace: default 
Labels: <none> 
Annotations: <none> 
Data 

appdatadir: 9 bytes 
loglevel: 4 bytes 


容 句 应 用 对 ConfigMap 的 使 用 有 以 下 两 种 方法 。 


(1) 通过 环境 变量 获取 ConfigMap 中 的 内 容 。 


(2) 通过 Volume 挂 载 的 方式 将 ConfigMap 中 的 内 容 挂 载 为 容器 内 
部 的 文件 或 目录 。 


4.ConfigMap 的 使 用 : 环境 变量 方式 
以 cm-appvars.yaml 为 例 : 


apiVersion: vi 
kind: ConfigMap 
metadata: 
name: cm-appvars 
data: 
apploglevel: info 
appdatadir: /var/data 


在 Pod“cm-test-pod” 的 定义 中 ， 将 ConfigMap“cm-appvars” 中 的 内 容 
以 环境 变量 (APPLOGLEVEL 和 APPDATADIR) 设置 为 容器 内 部 的 环 
境 变 量 ， 容 器 的 启动 命令 将 显示 这 两 个 环境 变量 的 值 (“envigrep 


APP”) 
apiVersion: vi 
kind: Pod 


metadata: 


name: cm-test-pod 


spec: 


containers: 
- name: cm-test 
image: busybox 


command: [ "/bin/sh", "-c", "env | grep APP" ] 


env: 
- name: APPLOGLEVEL # 定义 环境 变量 名 称 
valueFrom: 4 key“apploglevel” xt 
应 的 值 
configMapKeyRef : 
name: cm-appvars # 环境 变量 的 值 取 自 cm- 
appvars 中 : 
key: apploglevel 4 keyN“apploglevel” 
- name: APPDATADIR # 定义 环境 变量 名 称 
valueFrom: 4 key“appdatadir”’ Why 
的 值 
configMapKeyRef : 
name: cm-appvars # 环境 变量 的 值 取 自 cm- 
appvars 中 : 
key: appdatadir # keyA”appdatadir” 


restartPolicy: Never 


使 用 kubectl create-f 命 令 创建 该 Pod， 由 于 是 测试 Pod， 所 以 该 Pod 
在 执行 完 启 动 命令 后 将 会 退出 ， 并且 不 会 被 系统 目 动 重 局 


(restartPolicy=Never) 


# kubectl create -f cm-test-pod.yaml 


pod "cm-test-pod" created 


使 用 kubect] get pods--show-all 查 看 已 经 停止 的 Pod: 


# kubectl get pods --show-all 
NAME READY STATUS RESTARTS 
AGE 
cm-test-pod 0/1 Completed 0 


8s 


查看 该 Pod 的 日 志 ， 可 以 看 到 启动 命令 “env|grep APP” 的 执行 结果 
如 下 : 


# kubectl logs cm-test-pod 
APPDATADIR=/var/data 
APPLOGLEVEL=info 


WLBH A ae A SBA EA See E [SS FA ConfigMap cm-appvars 中 的 值 进行 了 
正确 的 设置 。 


5.ConfigMap 的 使 用 : volumeMount# X 


下 面 cm-appconfigfiles.yaml 的 例子 中 包含 两 个 配置 文件 的 定义 : 


server.xml 和 logging.properties ° 


cm-appconfigfiles.yaml 
apiVersion: vi 
kind: ConfigMap 


metadata: 


name: cm-serverxml 


data: 


key-serverxml: | 


< xml version='1.0' encoding='utf-8' > 


<Server port="8005" shutdown="SHUTDOWN"> 


className-"org.apache. 


r" /» 


className-"org.apache. 


SSLEngine="on" /» 


className-"org.apache. 


Listener" /» 


className-"org.apache. 


cleListener" /> 


className-"org.apache. 


onListener" /» 


catalina. 


catalina. 


catalina. 


catalina. 


catalina. 


<GlobalNamingResources> 


<Listener 


startup.VersionLoggerListene 


<Listener 


core.AprLifecycleListener" 


<Listener 


core. JreMemoryLeakPrevention 


<Listener 


mbeans.GlobalResourcesLifecy 


<Listener 


core. ThreadLocalLeakPreventi 


<Resource name="UserDatabase" auth="Container" 


type-"org.apache.catalina.UserDatabase" 


be updated and saved" 


description="User database that can 


factory="org.apache.catalina.users.MemoryUserDatabaseFactor 


y 


pathname="conf/tomcat-users.xml" /> 


</GlobalNamingResources> 


<Service name="Catalina"> 
<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" 
redirectPort="8443" /> 
<Connector port="8009" protocol="AJP/1.3" 
redirectPort="8443" /> 
«Engine name="Catalina" defaultHost="localhost"> 
<Realm 
className="org.apache.catalina.realm.LockOutRealm"> 
<Realm 
className="org.apache.catalina.realm.UserDatabaseRealm" 
resourceName="UserDatabase"/> 
</Realm> 
«Host name="localhost" appBase="webapps" 
unpackWARs="true" autoDeploy="true"> 
<Valve 
className="org.apache.catalina.valves.AccessLogValve" 
directory="logs" 
prefix-"localhost access log" 
suffix=".txt" 
pattern="%h %1 %u %t &quot;%r&quot; 


%S 96b" /> 


</Host> 
</Engine> 
</Service> 
</Server> 
key-loggingproperties: "handlers 
= i1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, 
3manager.org.apache.juli.FileHandler, 4host- 
manager.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler\r\n\r\n.handlers 


= 1catalina.org.apache.juli.FileHandler, 


java.util.logging.ConsoleHandler\r\n\r\nicatalina.org.apach 


e.juli.FileHandler.level 


FINE\r\nicatalina.org.apache. juli.FileHandler.directory = 
${catalina.base}/logs\r\nicatalina.org.apache. juli.FileHand 


ler.prefix 


catalina.NrNnNrNn21ocalhost.org.apache.juli.FileHandler.lev 
el = 


FINE\r\n2localhost.org.apache.juli.FileHandler.directory 


${catalina.base}/logs\r\n2localhost.org.apache. juli.FileHan 
dler.prefix = 


localhost.\r\n\r\n3manager.org.apache. juli.FileHandler.leve 


FINENrNn3manager.org.apache.juli.FileHandler.directory - 
${catalina.base}/logs\r\n3manager.org.apache. juli.FileHandl 
er.prefix 
= manager. \r\n\r\n4host - 
manager .org.apache. juli.FileHandler.level = FINE\r\n4host- 
manager .org.apache. juli.FileHandler.directory 
= ${catalina.base}/logs\r\n4host- 
manager .org.apache. juli.FileHandler.prefix = 
host- 
manager.NrNnNrNnjava.util.logging.ConsoleHandler.level - 


FINE\r\njava.util.logging.ConsoleHandler.formatter 


java.util.logging.SimpleFormatter\r\n\r\n\r\norg.apache.cat 
alina.core.ContainerBase.[Catalina].[localhost].level 
= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina]. [localhost].handlers 


2localhost.org.apache. juli.FileHandler\r\n\r\norg.apache.ca 
talina.core.ContainerBase.[Catalina].[localhost]. 
[/manager].level 

= INFO\r\norg.apache.catalina.core.ContainerBase. 


[Catalina].[localhost].[/manager].handlers 


3manager.org.apache. juli.FileHandler\r\n\r\norg.apache.cata 


lina.core.ContainerBase. [Catalina].[localhost].[/host- 


manager ].level 
= INFO\r\norg.apache.catalina.core.ContainerBase. 
[Catalina] .[localhost].[/host-manager ].handlers 
= 4host - 


manager .org.apache. juli.FileHandler\r\n\r\n" 


f£ Pod“cm-test-app” hJ «E X. F, + ConfigMap“cm-appconfigfiles” FH 
的 内 容 以 文件 的 形式 mount 到 容器 内 部 的 /configfiles 目 录 中 去 。Pod 配 
置 文件 cm-test-app.yaml 的 内 容 如 下 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: cm-test-app 
spec: 
containers: 
- name: cm-test-app 
image: kubeguide/tomcat-app:vi 
ports: 


- containerPort: 8080 


volumeMounts: 
- name: serverxml # 引用 volLume 名 
mountPath: /configfiles # 挂 载 到 容器 内 的 目录 
volumes: 
- name: serverxml # 定义 volume 名 
configMap: 


name: cm-appconfigfiles # 使 用 


ConfigMap"cm-appconfigfiles" 


items: 
- key: key-serverxml # key=key-serverxml 
path: server.xml # Value 将 server .Xml 
文件 名 进行 挂 载 
- key: key-loggingproperties # key=key- 
loggingproperties 


path: logging.properties 4 value 将 


logging .properties 文 件 名 进行 挂 载 


创建 该 Pod: 


# kubectl create -f cm-test-app.yaml 


pod "cm-test-app" created 


登录 容器 ， 查 看 到 /configfiles H a F 4 Æ server.xml 和 
logging.properties X: frt , € [f|] Hy Pj 4 it Æ ConfigMap*cm- 
appconfigfiles” 中 两 个 key 定 义 的 内 容 。 


# kubectl exec -ti cm-test-app -- bash 
root@cm-test-app:/# cat /configfiles/server.xml 
< xml version='1.0' encoding='utf-8' > 


<Server port="8005" shutdown="SHUTDOWN"> 


rootQcm-test-app:/£ cat 


/configfiles/logging.properties 


handlers = icatalina.org.apache.juli.AsyncFileHandler, 
2localhost.org.apache.juli.AsyncFileHandler, 
3manager.org.apache.juli.AsyncFileHandler, Ahost - 
manager.org.apache.juli.AsyncFileHandler, 


java.util.logging.ConsoleHandler 


如 果 在 引用 ConfigMap 时 不 指定 items， 则 使 用 volumeMount 方 式 在 
容器 内 的 目录 中 为 每 个 item 生 成 一 个 文件 名 为 key 的 文件 。 


Pod 配 置 文件 cm-test-app.yaml 的 内 容 如 下 : 


apiVersion: v1 
kind: Pod 
metadata: 
name: cm-test-app 
spec: 
containers: 
- name: cm-test-app 
image: kubeguide/tomcat -app: v1 
imagePullPolicy: Never 
ports: 


- containerPort: 8080 


volumeMounts: 
- name: serverxml # 引用 volume 名 
mountPath: /configfiles # 挂 载 到 容器 内 的 目录 


volumes: 


- name: serverxml # 定义 volume 名 


configMap: 


name: cm-appconfigfiles # 使 用 


ConfigMap"cm-appconfigfiles" 


创建 该 Pod: 


# kubectl create -f cm-test-app.yaml 


pod "cm-test-app" created 


登录 容器 ， 查 看 到 /configfiles 目 录 下 存在 key-loggingproperties 和 
key-serverxml 文 件 ， 文 件 的 名 称 来 目 ConfigMap cm-appconfigfiles "P XE 
义 的 两 个 key 的 名 称 ， 文 件 的 内 容 则 为 value 的 内 容 : 


# ls /configfiles 


key-loggingproperties key-serverxml 


6. 使 用 ConfigMap 的 限制 条 件 
使 用 ConfigMap 的 限制 条 件 如 下 。 


ConfigMap 必 须 在 Pod 之 前 创建 。 

ConfigMap 也 可 以 定义 为 属于 某 个 Namespace。 只 有 处 于 相同 
Namespaces 中 的 Pod 可 以 引用 它 

ConfigMap 中 的 配额 管理 还 未 能 实现 。 

kubelet 只 文生 可 以 被 APIServer 管 理 的 Pod 使 用 ConfigMap ° kubelet 
在 本 Node 上 通过 --manifestrurl 或 --config 目 动 创建 的 静态 Pod 将 无 法 


引用 ConfigMap ° 

在 Pod 对 ConfigMap 进 行 挂 载 (volumeMount) 操作 上 时， 容器 内 部 
只 能 挂 载 为 “目录 ”， 无 法 挂 载 为 “文件 ”*”。 在 挂 载 到 容器 内 部 后 ， 
目录 中 将 包含 ConfigMap 定 义 的 每 个 item， 如 果 该 目录 下 原先 还 有 
其 他 文件 ， 则 容 狗 内 的 该 目录 将 会 被 挂 载 的 ConfigMap 进 行 覆 
盖 。 如 果 应 用 程序 需要 保留 原来 的 其 他 文件 ， 则 需要 进行 额外 的 
处 理 。 可 以 通过 将 ConfigMap 挂 载 到 容 絮 内 部 的 临时 目录 ， 再 通 
过 启动 脚本 将 配置 文件 复制 或 者 链接 (cp 或 link 操 作 ) 到 应 用 所 用 
的 实际 配置 目录 下 。 


2.4.6 PodÆ an Js] HAAN Eta CS 


Pod te S&P an Fal WE PASE MAB MRAS, FARR P od & 
种 状态 对 于 我 们 理解 如 何 设置 Pod 的 调度 策略 、 重 启 策略 是 很 有 必要 
HY ° 


Pod 的 状态 包括 以 下 几 种 ， 如 表 2.14 所 示 。 
表 2.14 Pod 的 状态 


状态 值 描 述 
Pending API Server 已 经 创建 该 Pod, 但 Pod 内 还 有 一 个 或 多 个 容器 的 镜像 没有 创建 , 包括 正在 下 载 镜像 的 过 程 
Running Pod 内 所 有 容器 均 已 创建 ， 且 至 少 有 一 个 容器 处 于 运行 状态 、 正 在 启动 状态 或 正在 重启 状态 


Succeeded Pod 内 所 有 容器 均 成 功 执行 退出 ， 且 不 会 再 重启 


Failed Pod 内 所 有 容器 均 已 退出 ， 但 至 少 有 一 个 容器 退出 为 失败 状态 
Unknown 于 某 种 原因 无 法 获取 该 Pod 的 状态 ， 可 能 由 于 网 络 通信 不 畅 导 致 


Pod 的 重启 策略 (RestartPolicy) 应 用 于 Pod 内 的 所 有 容器 ， 并 且 仪 
在 Pod 所 处 的 Node 上 由 kubelet 进 行 判 断 和 重启 操作 。 当 某 个 容器 异常 
退出 或 者 健康 检查 ( 详 见 下 节 ) 失败 时 ，kubelet 将 根据 RestartPolicy 的 
设置 来 进行 相应 的 操作 。 


Pod 的 重启 策略 包括 Always ^ OnFailure 和 Never， 默 认 值 为 
Always ° 


e Always: 当 容 器 失效 时 ， 由 kubelet 目 动 重启 该 容器 ° 
e OnFailure: 当 容 需 终 止 运行 且 退 出 码 不 为 0 时 ， 由 kubelet 上 自动 重 局 


my Aa 


BGS o 


Ti 


e Never: 


仑 容器 运行 状态 如 何 ，kubelet 都 不 会 重启 该 容器 。 


kubelet 重 局 失效 容器 的 时 间 间 隅 以 sync-frequency 乘 以 2n 来 计算 ， 
例如 1、2、4、8 倍 等 ， 最 长 延 时 5 分 钟 ， 并 且 在 成 功 重 启 后 的 10 分 钟 后 


重 置 该 时 间 。 


Pod 的 重 局 党 略 与 控制 方式 轧 思 相关， 当前 可 用 于 管 evo 


au B], 
( 静 A Pod) 


« RCI DaemonSet: 


fi 


e Job: OnFailureBY Never, 


e kubelet: 


结合 Pod 的 状态 和 重 局 策略 ， 表 2.15 列 出 一 些 篆 


= 
E? 


Pod 包含 的 容器 数 


Wit Aas 


必须 设置 为 Always ， 


括 ReplicationController、Job、DaemonSet 及 直接 通 
"每 种 控制 逢 对 Pod 的 重 局 策略 要 求 如 下 。 


过 kubelet 管 理 


表 2.15 


Pod 当前 的 状态 


— JH er 


行 健康 检 WEE 2 


发 生 事 件 


季 见 的 状态 转换 场景 


Pod 的 结果 状态 


需要 保证 该 容器 持续 运 


执行 完成 后 不 再 重启 。 
在 Pome UE 已 ， 不 论 RestartPolicy 设 置 为 什么 
E, 并且 也 不 会 对 Pod 进 


E LARA RR 


RestartPolicy= 
Always 


RestartPolicy= 
OnFailure 


RestartPolicy= 
Never 


包含 1 个 容器 


Running 


容器 成 功 退 出 


Running 


Succeeded 


Succeeded 


包含 1 个 容器 


Running 


容器 失败 退出 


Running 


Running 


Failed 


包含 两 个 容器 


Running 


1 个 容器 失败 退出 


Running 


Running 


Running 


包含 两 个 容器 


Running 


容器 被 OOM 杀 掉 


Running 


Running 


Failed 


2.4.7 Pod 健康 检查 
LivenessProbe fil 


对 Pod 的 健康 状态 检查 可 以 通过 两 类 探 针 来 检查 
否 存活 running 状 态 ) ， 如 


ReadinessProbe ° 
RAS Ee 
果 LivenessProbe 探 针 探 测 到 容器 不 健康 ， 则 kubelet 将 杀 掉 该 容 
Bas BE 
BJ LivenessProbef& tl 


日 


e LivenessProbe 探 和 针 : 用 于 判断 
的 重 局 党 略 做 相应 的 处 理 。 如 果 一 个 
T ER 


器 ， 并 根据 
容器 是 否 启动 完成 (ready 状 态 ) ， 可 


cio 
LivenessProbe 探 针 ， 那 么 kubelet 认 为 该 
返回 的 值 永远 是 “Success”。 

e ReadinessProbe: 用 于 判断 E 
以 接收 请 求 。 如 果 ReadinessProbe 探 针 检 测 到 失败 ， 则 Pod 的 状态 
将 被 修改 。Endpoint Controller 将 从 Service 的 Endpoint 中 删除 包含 
所 在 Pod 的 Endpoint ° 
容 需 的 健康 状况 。 


EET 
kubelet 定期 执行 LivenessProbe 探 针 来 诊断 
如 果 该 命令 的 返回 


LivenessProbe 有 以 下 三 种 实现 方式 。 
(1) ExecAction: 在 容器 内 部 执行 一 个 命令 ， 
码 为 0， 则 表明 容 絮 健康 。 
在 下 面 的 例子 中 ， 通 过 执行 “cat/tmp/health”* 命 令 来 判断 一 个 容 絮 
运行 是 否 正 常 。 而 该 Pod 运 行 之 后 ， 在 创建 /tmp/health 文 件 的 10 秒 之 后 
删除 该 文件 ， 而 LivenessProbe 健康 检查 的 初始 探测 时 间 
探测 结果 将 是 Fail， 将 导致 kubelet 杀 


将 
(initialDelaySeconds) 为 15 秒 
并 重启 它 。 


掉 该 容器 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness-exec 
spec: 
containers: 
- name: liveness 
image: gcr.io/google containers/busybox 
args: 
- /bin/sh 
- -C 
- echo ok > /tmp/health; sleep 10; rm 
/tmp/health; sleep 600 
livenessProbe: 
exec: 
command: 
- cat 
- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


-rf 


(2) TCPSocketAction: 通过 容器 的 人 P 地 址 和 端口 号 执行 TCP 检 


查 ， 如 果 能 够 建立 TCP 连 接 ， ooo 8 健康 。 


在 下 面 的 例子 中 ， 通 过 与 容器 内 的 localhost 8088 V TCPXEPZXETT 
健康 检查 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: pod-with-healthcheck 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
livenessProbe: 
tcpSocket: 
port: 80 
initialDelaySeconds: 30 


timeoutSeconds: 1 


(3) HTIPGetAction: jHit ZE28HJIPJU HE ` vig [1-57 BS f Us] FH 
HTTP Get 方 法 ， 如 果 啊 应 的 状态 码 大 于 等 于 200 且 小 于 等 于 400， 则 认 
为 容器 状态 健康 。 


在 下 面 的 例子 中 ，kubelet 定 时 发 送 HTTP 请求 到 localhost: 
80/_status/healthz 来 进行 容器 应 用 的 健康 检查 。 


apiVersion: vi 
kind: Pod 
metadata: 
name: pod-with-healthcheck 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
livenessProbe: 
httpGet: 
path: / status/healthz 
port: 80 
initialDelaySeconds: 30 


timeoutSeconds: 1 


对 于 每 种 探测 方式 ， 都 需要 设置 initialDelaySeconds 和 
timeoutSeconds 两 个 参数 ， 它 们 的 含义 分 别 如 下 。 


e initialDelaySeconds: 启动 容 絮 后 进行 首次 健康 检查 的 等 待 时间， 
单位 为 秒 

e timeoutSeconds: 健康 检查 发 送 请 求 后 等 待 啊 应 的 超时 时 间 ， 单 位 
为 秒 。 当 超时 发 生 时 ，kubelet 会 认为 容器 已 经 无 法 提供 服务 ， 将 
会 重启 该 容器 。 


2.4.8” 玩 转 Pod 调 度 


在 Kubernetes 系 统 中 ，Pod 在 大 部 分 场景 下 都 只 是 容器 的 载体 而 
已 ， 通 常 需要 通过 RC、Deployment、DaemonSet、Job 等 对 象 来 完成 
Pod 的 调度 与 自动 控制 功能 。 


1.RC ` Deployment: 全 自动 调度 


RCH ERG Ze Ba TA A AS, DAR 
等 续 监 控 副 本 的 数量 ， 在 集群 内 始终 维持 用 户 指定 的 副本 数量 。 


根 据 frontend-controlleryaml 配置， 用 户 需 要 创建 3 个 
kubeguide/guestbook-php-frontend 应 用 的 副本 ， 在 将 该 定义 发 送 给 
Kubernetes 之 后 ， 系 统 将 在 集群 中 合适 的 Node 上 创建 3 个 Pod， 并 始终 
维持 3 个 副本 的 数量 。 


apiVersion: vi 
kind: ReplicationController 
metadata: 

name: frontend 

labels: 

name: frontend 

spec: 

replicas: 3 


selector: 


name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 
- name: frontend 
image: kubeguide/guestbook-php-frontend 
env: 
- name: GET HOSTS FROM 
value: env 
ports: 


- containerPort: 80 


在 调度 策略 上 ， 除 了 使 用 系统 内 置 的 调度 算法 选择 合适 的 Node 进 
行 调度 ， 也 可 以 在 Pod 的 定义 中 使 用 NodeSelector 或 NodeAffinity 来 指定 
满足 条 件 的 Node 进 行 调 度 ， 下 面 我 们 分 别 进 行 说 明 e 


1) NodeSelector: 定 同 调度 


Kubernetes Master 上 的 Scheduler 服 务 (kube-scheduler 进 程 ) 负责 

实现 Pod 的 调度 ， 整 个 调度 过 程 通 过 执行 一 系列 复杂 的 算法 ， 最 终 为 

每 个 Pod 计 算出 一 个 最 佳 的 目标 节点 ， 这 一 过 程 是 目 动 完成 的 ， 通 常 

我 们 无 法 知道 Pod 最 终 会 被 调度 到 哪个 节点 上 。 在 实际 情况 中 ， 也 可 

能 需要 将 Pod 调 度 到 指定 的 一 些 Node 上 ， 可 以 通过 Node 的 标签 
(Label) 和 Pod 的 nodeSelector 属 性 相 匹 配 ， 来 达到 上 述 目的 。 


AUS E ee pee 
SA H Y 
(1) 首先 通过 kubectl label 命 令 给 目标 Node 打 上 一 些 标 符 


kubectl label nodes <node-name><label-key>=<label- 


value> 


ixH, Hl] Ak8s-node-171) Z1] E.— "Tl zone-northB bz, RHE 
EAN 7H 二 


$ kubectl label nodes k8s-node-1 zone=north 
NAME LABELS 
STATUS 
k8s-node-1 kubernetes.io/hostname-k8s-node- 


1,zone-north Ready 


上 述 命 令 行 操 作 也 可 以 通过 修改 资源 定义 文件 的 方式 ， 并 执行 
kubectl replace-f xxx.yaml 命 令 来 完成 。 


(2) 然后 ， 在 Pod 的 定义 中 加 上 nodeSelector 的 设置 ， 以 redis- 


master-controller.yaml 为 例 : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 


replicas: 1 


selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 
spec: 
containers: 
- name: master 
image: kubeguide/redis-master 
ports: 
- containerPort: 6379 
nodeSelector: 


zone: north 


iB fT kubectl create-f 命 令 创 建 Pod，scheduler 束 会 将 该 Pod 调 度 到 拥 
有 zone=north 标 签 的 Node 上 。 


使 用 kubectl get pods-o wide 命令 可 以 验证 Pod 所 在 的 Node: 


# kubectl get pods -o wide 
NAME READY STATUS RESTARTS 
AGE NODE 
redis-master-fOrqj 1/1 Running 0 


19s k8s-node-1 


如 果 我 们 给 多 个 Node 都 定义 了 相同 的 标签 (例如 zone=north) 
则 scheduler 将 会 根据 调度 算法 从 这 组 Node 中 挑选 一 个 可 用 的 Node 进 行 
Pod 调 度 。 


通过 基于 Node 标 签 的 调度 方式 ， 我 们 可 以 把 集群 中 具有 不 同 特点 
的 Node Jh 上 A m 的 标 签 , 例 
如 “role=frontend”“role=backend”“role=database” 等 标签 ， 在 部 署 应 用 时 
就 可 以 根据 应 用 的 需求 设置 NodeSelector 来 进行 指定 Node 范 围 的 调 
度 o 


需要 注意 的 是 ， 如 果 我 们 指定 了 Pod 的 nodeSelector 条 件 ， 且 集群 
中 不 存在 包含 相应 标签 的 Node， 则 即使 集群 中 还 有 其 他 可 供 使 用 的 
Node， 这 个 Pod 也 无 法 被 成 功 调度 。 


2) NodeAffinity: 亲 和 性 调度 


NodeAffinity 意 为 Node 亲 和 人 性 的 调度 策略 ， 是 将 来 区 换 
NodeSelector 的 下 一 代 调 度 策略 。 由 于 NodeSelector 通 过 Node 的 Label 进 
行 精确 匹配 ， 所 以 NodeAffinity 增 加 f In ^ Notin ^ Exists ^ 
DoesNotExist、Gt、Lt 等 操作 符 来 选择 Node， 能 够 使 调度 策略 更 加 灵 
活 。 同 时 ， 在 NodeAffinity 中 将 增加 一 些 信息 来 设置 亲 和 人 性 调度 策略 。 


e RequiredDuringSchedulingRequiredDuringExecution : 类 WW F 
NodeSelector， 但 在 Node 不 满足 条 件 时 ， 系 统 将 从 该 Node 上 移 除 
之 前 调度 上 的 Pod e 

。 RequiredDuringSchedulingIgnoredDuringExecution : 与 第 1 个 
RequiredDuringSchedulingRequiredDuringExecution 的 作用 相似 ， 


区 别 是 在 Node 不 满足 条 件 时 ， 系 统 不 一 定 从 该 Node 上 移 除 之 前 调 
度 上 的 Pod 。 

。 PreferredDuringSchedulingIgnoredDuringExecution: 指定 在 满足 调 
度 条 件 的 Node 中 ， 哪 些 Node 应 更 优先 地 进行 调度 。 同 时 在 Node 不 
满足 条 件 时 ， 系 统 不 一 定 从 该 Node 上 移 除 之 前 调度 上 的 Pod 。 


在 当前 的 Alpha 版 本 中 ， 需 要 在 Pod 的 metadata.annotations 中 设置 
NodeAffinity 的 内 容 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: with-labels 
annotations: 
scheduler.alpha.kubernetes.io/affinity: » 


{ 
"nodeAffinity": { 


"requiredDuringSchedulingIgnoredDuringExecution": { 


"nodeSelectorTerms": [ 


{ 
"matchExpressions": [ 
{ 
"key": "kubernetes.io/e2e-az- 
name", 
"operator": "In", 


"values": ["e2e-azi", "e2e-az2"] 


} 
] 
} 
} 
} 
another-annotation-key: another-annotation-value 
spec: 
containers: 


- Name: with-labels 


image: gcr.io/google containers/pause:2.0 


iX Æ NodeAffinity B ix Ei Ui Bj H A Node BJ Label "P £ & 
key-kubernetes.io/e2e-az-name , 并 H. K value 7j *e2e-az1" BY “e2e- 
az2” 时 ， 才 能 成 为 该 Pod 的 调度 目标 。 其 中 操作 符 为 mh， 代表 “或 ” 运 
算 ， 其 他 操作 符 包 括 NotIn (不 属于 ) 、Exists (存在 一 个 条 件 ) ^ 
DoesNotExist (PFE) ^ Gt (KF) 、Lt (小 于 ) 。 


如 果 同 时 设置 了 NodeSelector 和 NodeAffinity， 则 系统 将 需要 同时 
满足 两 者 的 设置 才能 进行 调度 。 


在 未 来 的 Kubermetes 版 本 中 ， 还 将 加 入 Pod Affinity 的 设置 ， 用 于 
控制 当 调 度 Pod 到 某 个 特定 的 Node 上 上 时， 判断 是 否 有 其 他 Pod 正 在 该 
Node 上 运行 ， 即 通过 其 他 的 相关 Pod 进 行 调度 ， 而 不 仅仅 通过 Node 本 
寻 的 标签 进行 调度 。 


2.DaemonSet: 特定 场景 调度 


DaemonSet 是 Kubernetes 1.2 版 本 新 增 的 一 种 资源 对 象 ， 用 于 管理 
在 集群 中 每 个 Node 上 仪 运行 一 份 Pod 的 副本 实例 ， 如 图 2.10 所 示 。 


在 每 个 Node 上 运 
行 一 个 monitor 


Kubernetes Master 


ee 


monitor monitor monitor 
Pod Pod Pod 


Node 1 Node 2 Node 3 


图 2.10 DaemonSet7s {il 
这 种 用 法 适合 一 些 有 这 种 需求 的 应 用 。 


这 

。 在 每 个 Node 上 运行 一 个 GlusterFS 存 储 或 者 Ceph 存 储 的 daemon 进 
程 。 

。 在 每 个 Node 上 运行 一 个 日 志 采 集 程 序 ， 例 如 fluentd 或 者 logstach ° 

。 在 每 个 Node 上 运行 一 个 健康 程序 ， 采 集 该 Node 的 运行 性 能 数据 ， 
例如 Prometheus Node Exporter ^ collectd ^ New Relic agent 或 者 


Ganglia gmond 等 。 


DaemonSet 的 Pod 调 度 策略 与 RC 类 似 ， 除 了 使 用 系统 内 置 的 算法 
在 每 台 Node 上 进行 调度 ， 也 可 以 在 Pod 的 定义 中 使 用 NodeSelector 或 
NodeAffinity 来 指定 满足 条 件 的 Node 范 围 进行 调度 。 


下 面 的 例子 定义 为 在 每 台 Node 上 局 动 一 个 fuentd 容 器 ， 配 置 文件 
fluentd-ds.yaml 的 内 容 如 下 ， 其 中 挂 载 了 物理 机 的 两 个 目 
se “/var/log” #ll/var/lib/docker/containers” : 


apiVersion: extensions/vibetai 

kind: DaemonSet 

metadata: 
name: fluentd-cloud-logging 
namespace: kube-system 
labels: 


k8s-app: fluentd-cloud-logging 


spec: 
template: 
metadata: 
namespace: kube-system 
labels: 
k8s-app: fluentd-cloud-logging 
spec: 


containers: 
- name: fluentd-cloud-logging 
image: gcr.io/google containers/fluentd- 
elasticsearch:1.17 
resources: 
limits: 
cpu: 100m 
memory: 200Mi 


env: 


- name: FLUENTD_ARGS 
value: -q 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
readOnly: false 
- name: containers 
mountPath: /var/lib/docker/containers 
readOnly: false 
volumes: 
- name: containers 
hostPath: 
path: /var/lib/docker/containers 
- name: varlog 
hostPath: 


path: /var/log 


使 用 kubectl create 命 令 创 建 该 DaemonSet: 


# kubectl create -f fluentd-ds.yaml 


daemonset "fluentd-cloud-logging" created 


查看 创建 好 的 DaemonSet 和 Pod， 可 以 看 到 在 每 个 Node 上 都 创建 了 


一 个 Pod: 


# kubectl get daemonset --namespace=kube-system 


NAME DESIRED CURRENT NODE - 


SELECTOR AGE 
fluentd-cloud-logging 2 2 «none» 
3s 


# kubectl get pods --namespace-kube-system 

NAME READY STATUS 
RESTARTS AGE 

fluentd-cloud-logging-7tw9z 1/1 Running 0 
1h 

fluentd-cloud-logging-aqdn1 1/1 Running 0 
1h 


3.Job: 批 处 理 调度 


Kubernetes 从 1.2 版 本 开始 文 持 批 处 理 类 型 的 应 用 ， 我 们 可 以 通过 
KubernetesJob 资 源 对 象 来 定义 并 启动 一 个 批 处 理 任务 。 批 处 理 任务 通 
常 并 行 (MART) 启动 多 个 计算 进程 去 处 理 一 批 工 作 项 (work 
item) ， 处 理 完成 后 ， 整 个 批 处 理 任 务 结束 。 按 照 批 处 理 任务 实现 方 
式 的 不 同 ， 批 处 理 任务 可 以 分 为 如 图 2.11 所 示 的 几 种 模式 。 


Job Template Expansion Queue with Pod Per Work Item Queue with Variable Pod Count 


(o | Joh m 
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图 2.11 批 处 理 任务 的 几 种 模式 


e Job Template Expansion 模 式 : 一 个 Job 对 象 对 应 一 个 竺 处 理 的 Work 

item, ， 有 几 个 Work item 就 产生 几 个 独立 的 Job， 通 常 适 合 Work 

item 数 量 少 、 每 个 Work item 要 处 理 的 数据 量 比 较 大 的 场景 ， 比 如 

有 一 个 100GB 的 文件 作为 一 个 Work item， 总 共 10 个 文件 需要 处 

Ho 

Queue with Pod Per Work Item 模 式 : 采用 一 个 任务 队列 存放 Work 

item， 一 个 Job 对 象 作 为 消费 者 去 完成 这 些 Work item ， 在 这 种 模式 

下 ，Job 会 局 动 N 个 Pod， 每 个 Pod 对 应 一 个 Work item 。 

e Queue with Variable Pod Count 模 式 :， 也 是 采用 一 个 任务 队列 存放 
Work item， 一 个 Job 对 象 作为 消费 者 去 完成 这 些 Work item， 但 与 
上 面 的 模式 不 同 ，Job 局 动 的 Pod 数 量 是 可 变 的 。 


还 有 一 种 被 称 为 Single Job with Static Work Assignment 的 模式 ， 也 
是 一 个 Job 产 生 多 个 Pod 的 模式 ， 但 它 采 用 程序 静态 方式 分 配 任务 项 ， 
而 不 是 采用 队列 模式 进行 动态 分 配 。 


如 表 2.16 所 示 是 这 几 种 模式 的 一 个 对 比 。 


Pod 的 数量 少 于 | 用 户 程序 是 否 要 做 | Kubernetes 是 


me Work item 相应 的 修改 否 支持 


Job Template Expansion 


A 
Queue with Pod Per Work Item 是 / 有 时 候 需 要 


Queue with Variable Pod Count 


Single Job with Static Work Assignment | 是 / 是 


考虑 到 批 处 理 的 并 行 问 题 ，Kubernetes 将 Job 分 以 下 三 种 类 型 。 
1) Non-parallel Jobs 


通 浓 一 个 Job 只 启动 一 个 Pod， 则 除非 Pod 异 弟 ， 才 会 重启 该 Pod,， 
一 旦 此 Pod 正 常 结束 ，Job 将 结束 。 


2) Parallel Jobs with a fixed completion count 
并 行 Job 会 启动 多 个 Pod， 此 时 需要 设 定 Job 的 .spec.completions 参 数 
为 一 个 正 数 ， 当 正 弟 结束 的 Pod 数 量 达 到 此 参数 设 定 的 值 后 ，Job 结 


束 。 此 外 ，Job 的 .spec.parallelism 参 数 用 来 控制 并 行 度 ， 即 同时 启动 儿 
个 Job 来 处 理 Work Item ° 


3) Parallel Jobs with a work queue 


任务 队列 方式 的 并 行 Job 需 要 一 个 独立 的 Queue，Work item 都 在 一 
个 Queue 中 存放 ， 不 能 设置 Job 的 .spec.completions 参 数 ， 此 时 Job 有 以 
下 一 些 特性 。 


每 个 Pod 能 独立 判断 和 决定 是 否 还 有 任务 项 需要 处 理 。 

如 果 某 个 Pod 正 第 结束 ， 则 Job 不 会 再 局 动 新 的 Pod。 

如 果 一 个 Pod 成 功 结束 ， 则 此 时 应 该 不 存在 其 他 Pod 还 在 干 活 的 情 
况 ， 它 们 应 该 都 处 于 即将 结束 、 退 出 的 状态 。 


。 如 末 所 有 Pod 都 结束 了 ， 且 至 少 有 一 个 Pod 成 功 结束 ， 则 整个 Job 算 
是 成 功 结束 。 


下 面 我 们 分 别 说 说 常见 的 三 种 批 处 理 模 型 在 Kubernetes 中 的 例 
子 。 


首先 是 Job Template Expansion 模 式 ， 由 于 这 种 模式 下 每 个 Work 
item 对 应 一 个 Job 实 例 ， 所 以 这 种 模式 首先 定义 一 个 Job 模 板 ， 模 板 里 
主要 的 参数 是 work item 的 标识 ， 因 为 每 个 Job 处 理 不 同 的 Work item。 
如 下 所 示 的 Job 模 板 (文件 名 为 job.yaml.txt) 中 的 $ITEM 可 以 作为 任务 
项 的 标识 : 


apiVersion: batch/v1 
kind: Job 
metadata: 
name: process-item-$ITEM 
labels: 
jobgroup: jobexample 
spec: 
template: 
metadata: 
name: jobexample 
labels: 
jobgroup: jobexample 
spec: 
containers: 


- name: c 


image: busybox 
command: ["sh", "-c", "echo Processing item 
$ITEM&& sleep 5"] 


restartPolicy: Never 


通过 下 面 的 操作 ， 生 成 3 个 对 应 的 Job 定 义 文 件 并 创建 Job: 


# for i in apple banana cherry 
> do 
> cat job.yaml.txt | sed "s/\$ITEM/$i/" > 

./jobs/job-$i.yaml 

> done 

# 1s jobs 

job-apple.yaml  job-banana.yaml  job-cherry.yaml 

# kubectl create -f jobs 

job "process-item-apple" created 

job "process-item-banana" created 


job "process-item-cherry" created 


观察 Job 的 运行 情况 : 


# kubectl get jobs -1 jobgroup=jobexample 


NAME DESIRED SUCCESSFUL AGE 
process-item-apple 1 1 4m 
process-item-banana 1 1 4m 


process-item-cherry 1 1 4m 


其 次 ， 我 们 看 看 Queue with Pod Per Work Item 模 式 ， 在 这 种 模式 
下 需要 一 个 任务 队列 存放 Work item， 比 如 RabbitMQ， 客 户 端 程序 先 把 
要 处 理 的 任务 变 成 Work item 放 入 到 任务 队列 ， 然 后 编写 Worker 程 序 并 
打包 镜像 并 定义 成 为 Job 中 的 Work Pod，Worker 程 序 的 实现 逻辑 是 从 任 
务 队 列 中 拉 取 一 个 Work item 并 处 理 ， 处 理 完 成 后 即 结束 进程 ， 图 2.12 
给 出 了 并 行 度 为 2 的 一 个 Demo 示 意图 。 


最 后 ， 我 们 再 看 看 Queue with Variable Pod Count 模 式 ， 如 图 2.13 所 
示 ， 由 于 这 种 模式 下 ，Worker 程 序 需 要 知道 队列 中 是 否 还 有 等 待 处 理 
的 Work item， 如 有 果 有 就 取 出 来 并 人 处理 ， 否 则 就 认为 所 有 工作 完成 并 结 
束 进程 ， 所 以 任务 队列 通常 要 采用 Redis 或 者 数据 库 来 实现 。 


RabbitMQ 


K8s Job 


任意 时 刻 ， 最 多 只 有 2 个 pod 存 在 


EZS 
每 个 Pod 对 应 一 个 工作 项 ， 即 处 理 完 一 个 ，Pod 就 结束 了 


产生 8 个 工作 项 


图 2.12 Queue with Pod Per Work Item 示 例 


RabbitMQ 并 不 能 让 客户 端 知道 是 否 
没有 数据 了 (客户 端 只 能 傻 等 ) ， 
”此 这 里 采用 了 Redis 队 列 


K8s Job 


产生 8 个 工作 项 
| Worker Pod 
f Worker Pod 


| Worker Pod 


每 个 Pod 都 不 断 地 从 队列 中 拉 取 工作 项 并 处 理 ， 直到 队列 为 空 ， Pig a 因此 ， 这 
种 情况 下 ， 只 要 有 一 个 Pod 成 功 结束 ， 就 意味 着 整个 job 进入 “终止 ”状态 。 


图 2.13 Queue with Variable Pod Count 示 例 


Kubermnetes 对 Job 的 支持 还 处 于 初级 阶段 ， 类 似 Linux Cron 的 定时 
任务 也 还 没 时 间 ， 计 划 在 Kubernetes 1.4 中 实现 。 此 外 ， 更 为 复杂 的 流 
程 类 的 批 处 理 框 以 也 还 没有 考虑 ， 但 随 着 Kubernetes 生 态 圈 的 不 断 发 
展 和 壮大 ， 相 信 Kubernetes 在 批 处 理 方面 也 会 有 更 多 的 规划 。 


2.4.9 Pod 的 扩容 和 缩 容 


在 实际 生产 系统 中 ， 我 们 经 常会 遇 到 某 个 服务 需要 扩容 的 场景 ， 
也 可 能 会 遇 到 由 于 资源 紧张 或 者 工作 负载 降低 而 需要 减少 服务 实例 数 
量 的 场景 。 此 时 我 们 可 以 利用 RC 的 Scale 机 制 来 完成 这 些 工作 。 以 
redis-slave RC 为 例 ， 已 定义 的 最 初 副 本 数量 为 2， 通 过 kubectl scale 命 
令 可 以 将 redis-slave RC 探 制 的 Pod 副 本 数量 从 初始 的 2 更 新 为 3: 


$ kubectl scale rc redis-slave --replicas=3 


replicationcontroller "redis-slave" scaled 


执行 kubectl get pods 命 令 来 验证 Pod 的 副本 数量 增加 到 3: 


$ kubectl get pods 


NAME READY STATUS RESTARTS 
AGE 

redis-slave-4na2n 1/1 Running 0 1h 

redis-slave-92u3k 1/1 Running 0 1h 


redis-slave-palab 1/1 Running 0 2m 


将 --replicas 设 置 为 比 当前 Pod 副 本 数量 更 小 的 数字 ， 系 统 将 会 < 杀 
掉 ” 一 些 运行 中 的 Pod， 以 实现 应 用 集群 缩 容 : 


$ kubectl scale rc redis-slave --replicas=1 


replicationcontroller "redis-slave" scaled 


$ kubectl get pods 
NAME READY STATUS 
RESTARTS AGE 
redis-slave-4na2n 1/1 Running 0 


1h 


除了 可 以 手工 通过 kubectl scale 命 令 完成 Pod 的 扩容 和 缩 容 操作 ， 

Kubernetes v1.1 版 本 新 增 了 名 为 Horizontal Pod Autoscaler (HPA) 的 控 
制 器 ， 用 于 实现 基于 CPU 使 用 率 进 行 目 动 Pod 扩 缩 容 的 功能 。HPA 控 制 
am 2 T Master H kube-controller-manager flit 4 Ja 5) Z 2 --horizontal-pod- 
autoscaler-sync-period 定 义 的 时 长 (默认 为 30 秒 ) ， 周 期 性 地 监测 目标 
Pod 的 CPU 使 用 率 ， 并 在 满足 条 件 时 对 ReplicationController 或 
Deployment 中 的 Pod 副 本 数量 进行 调整 ， 以 符合 用 户 定 义 的 平均 Pod 
CPU 使 用 率 。PodCPU 使 用 率 来 源 于 heapster 组 件 ， 所 以 需要 预先 安装 
好 heapster ° 


创建 HPA 时 可 以 使 用 kubectlautoscale 命 令 进行 快速 创建 或 者 使 用 
yaml 配 置 文件 进行 创建 。 在 创建 HPA 之 前 ， 需 要 已 经 存在 一 个 RC 或 
Deployment ¥f 4 , Jf H iX RC ZY Deployment AY) Pod 4D» M FE X. 
resources.requests.cpu 的 资源 请 求 值 ， 如 有 果 不 设 置 该 值 ， 则 heapster 将 无 
法 采集 到 该 Pod 的 CPU 使 用 情况 ， 会 导致 HPA 无 法 正常 工作 。 


下 面 通 过 给 一 个 RC 设 置 HPA， 然 后 使 用 一 个 客户 端 对 其 进行 压力 
测试 ， 对 HPA 的 用 法 进行 示例 。 


以 php-apache 的 RC 为 例 ， 设 置 cpu request 200m, Rix limit 上 
限 的 值 : 


php-apache-rc.yaml 
apiVersion: v1 
kind: ReplicationController 
metadata: 

name: php-apache 
spec: 

replicas: 1 

template: 

metadata: 

name: php-apache 

labels: 
app: php-apache 

spec: 

containers: 

- name: php-apache 
image: gcr.io/google containers/hpa-example 
resources: 

requests: 
cpu: 200m 
ports: 


- containerPort: 80 


# kubectl create -f php-apache-rc.yaml 


replicationcontroller "php-apache" created 


再 创建 一 个 php-apache 的 Service， 供 客户 端 访 问 : 


php-apache-svc.yaml 
apiVersion: v1 
kind: Service 
metadata: 

name: php-apache 
spec: 

ports: 

- port: 80 

selector: 


app: php-apache 


# kubectl create -f php-apache-svc.yaml 


service "php-apache" created 


fe F2EJJRC"php-apache"8]$& — HPAfzTB|28, 7E1F010Z lal SS 
Pod 的 副本 数量 ， 以 使 得 平均 Pod CPU 使 用 率 维持 在 50%。 


使 用 kubectl autoscale 命 令 进 行 创建 : 


# kubectl autoscale rc php-apache --min=1 --max=10 -- 


cpu-percent-50 


或 者 通过 yaml 配 置 文件 来 创建 HPA， 需 要 在 scaleTargetRef 字 段 指 
定 需 要 管理 的 RC 或 Deployment 的 名 字 ， 然 后 设置 minReplicas、 
maxReplicas 和 targetCPUUtilizationPercentage 参 数 : 


hpa-php-apache.yaml 
apiVersion: autoscaling/vi 
kind: HorizontalPodAutoscaler 
metadata: 
name: php-apache 
spec: 
scaleTargetRef: 
apiVersion: vi 
kind: ReplicationController 
name: php-apache 
minReplicas: 1 
maxReplicas: 10 


targetCPUUtilizationPercentage: 50 


# kubectl create -f hpa-php-apache.yaml 


horizontalpodautoscaler "php-apache" created 


查看 已 创建 的 HPA: 


# kubectl get hpa 
NAME REFERENCE TARGET 
CURRENT MINPODS MAXPODS AGE 
php-apache ReplicationController/php-apache 50% 


0% 1 10 im 


然后 ， 我 们 创建 一 个 busybox Pod， 用 于 对 php-apache 服 务 发 起 压 
力 测试 的 请 求 : 


busybox-pod.yaml 
apiVersion: vi 
kind: Pod 
metadata: 

name: busybox 
spec: 

containers: 

- name: busybox 

image: busybox 


command: [ "sleep", "3600" ] 


# kubectl create -f busybox-pod.yaml 


pod "busybox" created 


Zk K busybox Z at, MÍT — T FCB ABA AY weet fn 
apache 服 务 : 


命令 来 访问 php- 


# while true; do wget -q -0- http://php-apache > 


/dev/null; done 


注意 这 里 wget 的 目的 地 URL 地 址 是 Service 的 名 称 “php-apache”， 这 
要 求 DNS 服务 正 弟 工作 ， 也 可 以 使 用 Service 的 虚拟 ClusterIP 地 址 对 其 


进行 访问 ， 例 如 http:/169.169.122.145: 


# kubectl exec -ti busybox -- sh 


/ # while true; do wget -q -0- http://php-apache > 


/dev/null; done 


SERI BRUN BUS, XÉSEHPATEEBI 2818 888] Pod CPU 使 用 率 : 


# kubectl get hpa 


NAME REFERENCE 


TARGET 
CURRENT MINPODS MAXPODS 


AGE 
php-apache 


ReplicationController/php-apache 
3068% 1 


10 3m 


50% 


再 过 一 会 儿 ， 查 看 RC php-apache 副 本 数量 的 变化 : 


# kubectl get rc 


NAME DESIRED CURRENT 


php-apache 10 


AGE 


10 23m 


可 以 看 到 HPA 已 经 根据 Pod 的 CPU 使 用 率 的 提高 对 RC 进 行 了 目 动 
扩容 ，Pod 副 本 数量 变 成 了 10 个 。 这 个 过 程 如 图 2.14 所 示 。 
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图 2.14 HPA 自 动 扩 容 


最 后 ， 我 们 停止 压力 测试 ， 在 busybox 的 控制 台 输 入 Ctrl+C， 停 止 
无 限 循环 操作 。 


等 待 一 段 时 间 ， 观 察 HPA 的 变化 : 


# kubectl get hpa 
NAME REFERENCE TARGET 


CURRENT MINPODS MAXPODS AGE 
php-apache ReplicationController/php-apache 50% 


3% 1 10 20m 


再 次 查看 RC 的 副本 数量 : 


NAME DESIRED CURRENT AGE 


php-apache 1 1 26m 


可 以 看 到 HPA 根 据 Pod CPU 使 用 率 的 降低 对 副本 数量 进行 了 缩 容 
操作 ，Pod 副 本 数量 变 成 了 1 个 。 


当前 HPA 还 只 文 持 将 CPU 使 用 率 作 为 Pod 副 本 扩容 缩 容 的 触发 条 
件 ， 在 将 来 的 版 本 中 ， 将 会 支持 应 用 相关 的 指标 例如 QPS (queries per 
second) 或 平均 啊 应 时 间作 为 触发 条 件 。 


2.4.10 Pod 的 滚动 升级 


下 面 我 们 说 说 Pod 的 升级 问题 。 


当 集 群 中 的 某 个 服务 需要 升级 时 ， 我 们 需要 停止 目前 与 该 服务 相 
天 的 所 有 Pod， 然 后 重新 拉 取 镜像 并 启动。 如 采集 群 规模 比较 大 ， 则 
这 个 工作 就 变 成 了 一 个 挑战 ， 而 且 先 全 部 停止 然后 逐步 升级 的 方式 会 
导致 较 长 时 间 的 服务 不 可 用 。Kubernetes 提 供 了 rolling-update ( 深 动 升 
级 ) 功能 来 解决 上 述 问 题 。 


滚动 升级 通过 执行 kubectl rolling-update 命 令 一 键 完 成 ， 该 命令 创 
建 了 一 个 新 的 RC， 然 后 目 动 控制 旧 的 RC 中 的 Pod 副 本 的 数量 逐渐 减少 
到 0， 同 时 新 的 RC 中 的 Pod 副 本 的 数量 从 0 逐步 增加 a 到 目标 值 ， 最 终 实 
现 了 Pod 的 升级 。 需 要 注意 的 是 ， 系 统 要 求 新 的 RC 需 要 与 日 的 RC 在 相 
同 的 命名 空间 (Namespace) 内 ， 即 不 能 把 别人 的 资产 偷偷 转移 到 上 自 
家 名 下 。 深 动 升 级 的 过 程 如 图 2.15 所 示 。 
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图 2.15 ”Pod 的 滚动 升级 


以 redis-master 为 例 ， 假 设 当前 运行 的 redis-master Pod 是 1.0 版 本 ， 
则 现在 需要 升级 到 2.0 版 本 。 


创建 redis-master-controller-v2.yaml 的 配置 文件 如 下 : 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-master-v2 
labels: 
name: redis-master 
version: v2 
spec: 
replicas: 1 
selector: 
name: redis-master 
version: v2 
template: 
metadata: 
labels: 
name: redis-master 
version: v2 
spec: 
containers: 


- name: master 


image: kubeguide/redis-master:2.0 
ports: 


- containerPort: 6379 


FERC OCHRE we BEEN BLA ° 


(1) RC 的 名 字 (name) 不 能 与 旧 的 RC 的 名 字 相 同 。 


(2) 在 selector 中 应 至 少 有 一 个 Label 与 旧 的 RC 的 Label 不 同 ， 以 标 
识 其 为 狐 的 RC。 本 例 中 新 增 了 一 个 名 为 version 的 Label， 以 与 旧 的 RC 
in 


a 


分 o 
运行 kubectl rolling-update 命 令 完 成 Pod 的 滚动 升级 : 


kubectl rolling-update redis-master -f redis-master- 


controller-v2.yaml 


kubect 的 执行 过 程 如 下 : 


Creating redis-master-v2 
At beginning of loop: redis-master replicas: 2, redis- 
master-v2 replicas: 1 
Updating redis-master replicas: 2, redis-master-v2 
replicas: 1 
At end of loop: redis-master replicas: 2, redis- 
master-v2 replicas: 1 
At beginning of loop: redis-master replicas: 1, redis- 


master-v2 replicas: 2 


Updating redis-master replicas: 1, redis-master-v2 
replicas: 2 
At end of loop: redis-master replicas: 1, redis- 
master-v2 replicas: 2 
At beginning of loop: redis-master replicas: 0, redis- 
master-v2 replicas: 3 
Updating redis-master replicas: 0, redis-master-v2 
replicas: 3 
At end of loop: redis-master replicas: 0, redis- 
master-v2 replicas: 3 
Update succeeded. Deleting redis-master 


redis-master-v2 
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另 一 种 方法 是 不 使 用 配置 文件 ， 直 接 用 kubectl rolling-update fti 
令 ， 加 上 --image 参 数 指定 新 版 镜像 名 称 来 完成 Pod 的 滚动 升级 : 


kubectl rolling-update redis-master --image=redis- 


master:2.0 


与 使 用 配置 文件 的 方式 不 同 ， 执 行 的 结果 是 旧 的 RC 被 删除 ， 新 的 
RC 仍 将 使 用 旧 的 RC 的 名 字 。 


kubect 的 执行 过 程 如 下 : 


Creating redis-master-ea866a5d2c08588c3375b86fb253db75 
At beginning of loop: redis-master replicas: 2, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 1 
Updating redis-master replicas: 2, redis-master- 
ea866a5d2c08588c3375b86fb253db75 replicas: 1 
At end of loop: redis-master replicas: 2, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 1 
At beginning of loop: redis-master replicas: 1, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 2 
Updating redis-master replicas: 1, redis-master- 
ea866a5d2c08588c3375b86fb253db75 replicas: 2 
At end of loop: redis-master replicas: 1, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 2 
At beginning of loop: redis-master replicas: 0, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 3 
Updating redis-master replicas: 0, redis-master- 
ea866a5d2c08588c3375b86fb253db75 replicas: 3 
At end of loop: redis-master replicas: 0, redis- 
master-ea866a5d2c08588c3375b86fb253db75 replicas: 3 
Update succeeded. Deleting old controller: redis- 
master 
Renaming redis-master-ea866a5d2c08588c3375b86fb253db75 
to redis-master 


redis-master 


可 以 看 到 ，kubect 通 过 新 建 一 个 新 版 本 Pod， 停 掉 一 个 旧版 本 
Pod， 了 逐步 迭代 来 完成 整个 RC 的 更 新 。 


更 新 完成 后 ， 查 看 RC: 


$ kubectl get rc 


CONTROLLER CONTAINER(S) IMAGE(S) 
SELECTOR REPLICAS 
redis-master master kubeguide/redis - 


master:2.0 
deployment=ea866a5d2c08588c3375b86fb253db75, name=redis - 


master, version=v1 3 


可 以 看 到 ，kubectl 给 RC 增加 了 一 个 key 为 “deployment” 的 Label 
(这 个 key 的 名 字 可 通过 --deployment-label-key 参 数 进 行 修改 ) ，Label 
的 值 是 RC 的 内 容 进 行 Hash 计 算 后 的 值 ， 相 当 于 签名 ， 这 样 束 能 很 方便 
地 比较 RC 里 的 Image 名 字 及 其 他 信息 是 否 发 生 了 变化 ， 它 的 具体 作用 
可 以 参见 第 6 章 的 源码 分 析 。 


如 宁 在 更 新 过 程 中 发 现 配置 有 误 ， 则 用 户 可 以 中 断 更 新 操作 ， 并 
通过 执行 kubect rolling-update-rollback 完 成 Pod 版 本 的 回 深 : 


$  kubectl rolling-update redis-master -- 
image=kubeguide/redis-master:2.0 --rollback 

Found existing update in progress (redis-master - 
fefd9752aa5883ca4d53013a7b583967), resuming. 

Found desired replicas.Continuing update with existing 


controller redis-master. 


At beginning of loop: redis-master- 
fefd9752aa5883ca4d53013a7b583967 replicas: ©, redis-master 
replicas: 3 

Updating redis-master-fefd9752aa5883ca4d53013a7b583967 
replicas: 0, redis-master replicas: 3 
At end of loop: redis-master- 
fefd9752aa5883ca4d53013a7b583967 replicas: ©, redis-master 
replicas: 3 
Update succeeded. Deleting redis-master- 
fefd9752aa5883ca4d53013a7b583967 


redis-master 


到 此 ， 可 以 看 到 Pod 恢 复 到 更 新 前 的 版 本 了 。 


2.5 ”深入 掌握 Service 


Service 是 Kubernetes 最 核心 的 概念 ， 通 过 创建 Service， 可 以 为 一 
组 具有 相同 功能 的 容器 应 用 提供 一 个 统一 的 入 口 地 址 ， 并 有 旦 将 请 求 进 
行人 负载 分 发 到 后 端的 各 个 容器 应 用 上 。 本 节 对 Service 的 使 用 进行 详细 
说 明 ， 包 括 Service 的 负载 均衡 、 外 网 访问 、DNS 服 务 的 搭建 、Ingress 
7 层 路 由 机 制 等 。 


2.5.1 ”Service 定 义 详解 


yaml 格 式 的 Service 定 义 文件 的 完整 内 容 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 

name: string 

namespace: string 

labels: 
- name: string 
annotations: 
- name: string 
spec: 

selector: [] 

type: string 

clusterIP: string 

sessionAffinity: string 
ports: 

- name: string 
protocol: string 
port: int 
targetPort: int 


nodePort: int 


// 
// 
// 
// 


// 
// 
// 


// Required 
Required 
Required 
Required 


Required 


Required 
Required 


Required 


status: 
loadBalancer: 
ingress: 
ip: string 


hostname: string 


对 各 属性 的 说 明 如 表 2.17 所 示 。 
表 2.17 ”对 Service 的 定义 文件 模板 的 各 属性 的 说 明 


e e e — — — — — —À 


|uemhaame [sme [Reid | Service 2k, AFA RFC 1035 B 

| metadata namespace [string [Required 。 | 命名 宝 间 ， 不 指定 系统 时 将 使 用 名 为 “default” 的 从 名 空间 
| metadata tabe ict, | ex 
[metadataamnotstionf) [ie | [eam O o | 
[aee it | Requires [ives | 


管理 范围 


spec type string Required Service 的 类 型 ， 指定 Service 的 访问 方式 , 默认 为 ClusterIP。 
ChusterIP: 虐 氢 的 服务 IP 地 址 ， 该 地 址 用 于 Kubemetes 集群 
内 部 的 Pod 访问 , 在 Node 上 kube-proxy 通过 设置 的 iptables 
规则 进行 转发 。 
NodePort: 使 用 宿主 机 的 端口 ， 使 能 够 访问 备 Node 的 外 部 客 
户 端 通过 Node 的 下 地 址 和 端口 号 就 能 访问 服务 。 
LoadBalancer: 使 用 外 接 负载 均 稀 器 完成 到 服务 的 负载 分 发 ， 
需要 在 spec.status.loadBalancer 字段 指定 外 部 负载 均衡 器 的 
IP 地 址 ， 并 同时 定义 nodePort 和 clusterIP， 用 于 公有 云 环境 


spec.clusterIP string MEU Ss IP 地 址 ， 当 type=ClusterIP 时 ， 如 果 不 指定 ， 则 系 
时 ， 则 需要 指定 
ClientIP: 表示 将 同一 个 客户 端 ORE E PRI IP 地 址 决定 ) 
的 访问 请 求 都 转发 到 同一 个 后 端 Pod 


[veepos ji [| Service ROI — 0 | 
[specpons(imame | 
jpeeporslprotocl [sting |  — [rri 3H TCP &UDP. RUAT | 
[meseeüpn fa — (| maamo i 
|mecpord[]urgePon [int | MNRAS Poa MM | 
|weeper[]nedePot fit | [*ispeetrpecNodePon mi, MRNAS | 


当 spec type-LoadBalancer 时 ， 设 置 外 部 负载 均衡 器 的 地 址 ， 
于 公有 云 环境 


ee —— jue O ŘS 
[smmslsiBahnesinges [object | — 6 [smsmsmm — o | 
[statusloadBalanceringessip [sting | | 外 部 负载 均 衡器 的 P 地 址 | 
[mmskadBibmesingesbomame | sering || vhosts eee | 


2.5.2 Serviced A Hj 1X: 


一 般 来 说 ， 对 外 提供 服务 的 应 用 程序 需要 通过 某 种 机 制 来 实现 ， 
对 于 容 狼 应 用 最 简便 的 方式 就 是 通过 TCP/IP 机 制 及 监 昕 IP 和 羡 口 号 来 
实现 。 例 如 ， 我 们 定义 一 个 提供 Web 服 务 的 RC， 由 两 个 tomcat 容 器 副 
本 组 成 ， 每 个 容器 通过 containerPort 设 置 提 供 服 务 的 端口 号 为 8080: 


webapp-rc.yaml 
apiVersion: vi 
kind: ReplicationController 
metadata: 
name: webapp 
spec: 
replicas: 2 
template: 
metadata: 
name: webapp 
labels: 
app: webapp 
spec: 
containers: 
- name: webapp 


image: tomcat 


ports: 


-containerPort: 80 


创建 该 RC: 


# kubectl create -f webapp-rc.yaml 


replicationcontroller "webapp" created 


获取 Pod 的 IP 地 址 : 


# kubectl get pods -1 app=webapp -o yaml | grep podIP 
podIP: 172.17.1.4 
podIP: 172.17.1.3 


访问 这 两 个 Pod 提 供 的 Tomcat 服 务 : 


# curl 172.17.1.3:8080 
<!DOCTYPE html» 
«html lang="en"> 
<head> 
<meta charset="UTF-8" /> 
<title>Apache Tomcat/8.0.35</title> 
# curl 172.17.1.4:8080 
<!DOCTYPE html» 
«html lang="en"> 


<head> 


<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


直接 通过 Pod 的 IP 地 址 和 端口 号 可 以 访问 容器 应 用 ， 但 是 Pod 的 IP 
地 址 是 不 可 靠 的 ， 例 如 当 Pod 所 在 的 Node 发 生 故 障 时 ，Pod 将 被 
Kubernetes 重 狐 调度 到 另 一 台 Node 进 行 局 动 ，Pod 的 卫 地 址 将 发 生变 
化 。 更 重要 的 是 ， 如 果 容 器 应 用 本 吴 是 分 布 式 的 部 署 方式 ， 通 过 多 个 
实例 共同 提供 服务 ， 残 需要 在 这 些 实例 的 前 端 设置 一 个 负载 均衡 需 来 
实现 请 求 的 分 发 。Kubernetes 中 的 Service 就 是 设计 出 来 用 于 解决 这 些 
问题 的 核心 组 件 。 


以 前 面 创 建 的 webapp 应 用 为 例 ， 为 了 证 客户 端 应 用 能 够 访问 到 两 
个 Tomcat Pod 实 例 ， 需 要 创建 一 个 Service 来 提供 服务 。Kubernetes 提 供 
了 一 种 快速 的 方法 ， 即 通过 kubectl expose 命 令 来 创建 Service: 


# kubectl expose rc webapp 


service "webapp" exposed 


Be wr Pl Service, HUF RAREN SS AIP He 
HE (ClusterIP) ， 而 Service 所 需 的 端口 号 则 从 Pod 中 的 containerPort 复 
制 而 来 : 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
AGE 


webapp 169.169.235.79<none>8080/TCP 3s 


fe ROK, Fe Cay DS ct Service JIPJ ERI ServiceH)¥ig L1-5 17 fa] 
Service J : 


# curl 169.169.235.79:8080 
<!DOCTYPE html» 
<html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


这 里 ， 对 Service 地 址 169.169.235.79: 8080 的 访问 被 自动 负载 分 发 
到 了 后 端 两 个 Pod 之 一 : 172.17.1.3: 80802X172.17.1.4: 8080 ° 


除了 使 用 kubectl exzpose 命 令 创建 Service， 我 们 也 可 以 通过 配置 文 
件 定 义 Service， 再 通过 kubectl create 命 令 进 行 创 建 。 例 如 对 于 前 面 的 
webapp 应 用 ， 我 们 可 以 设置 一 个 Service， 代 码 如 下 : 


apiVersion: vi 
kind: Service 
metadata: 

name: webapp 
spec: 

ports: 

- port: 8081 


targetPort: 8080 


selector: 


app: webapp 


Service 定 义 中 的 关键 字段 是 ports 和 selector。 本 例 中 ports 定 义 部 分 
指定 了 Service 所 需 的 虚拟 端口 号 为 8081， 由 于 与 Pod 容 器 端口 号 8080 
不 一 样 ， 所 以 需要 再 通过 targetPort 来 指定 后 端 Pod 的 端口 号 。selector 
定义 部 分 设置 的 是 后 端 Pod 所 拥有 的 label: app-webapp ° 


创建 该 Service 并 查看 其 ClusterIP 地 址 : 


# kubectl create -f webapp-svc.yaml 


service "webapp" created 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
AGE 


webapp 169.169.28.190<none>8081/TCP 3s 
通过 Service 的 IP 地 址 和 Service 的 端口 号 进行 访问 : 


# curl 169.169.28.190:8081 
<!DOCTYPE html» 
«html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


同样 ， 对 Service 地 址 169.169.28.190: 8081 的 访问 被 自动 负载 分 发 
到 了 后 端 两 个 Pod 之 一 : 172.17.1.3: 8080 或 172.17.1.4: 8080。 目 前 
Kubemetes 提 供 了 两 种 负载 分 发 策略 : RoundRobin 和 SessionAffinity , 
具体 说 明 如 下 。 


e RoundRobin: 轮 询 模式 ， 即 轮 询 将 请 求 转发 到 后 端的 各 个 Pod 
上 。 

。 SessionAffinity: 基于 客户 端 卫 地 址 进行 会 话 保 持 的 模式 ， 即 第 1 
次 将 某 个 客户 端 发 起 的 请 求 转发 到 后 端的 某 个 Pod 上 ， 之 后 从 相 
同 的 客户 端 发 起 的 请 求 都 将 被 转发 到 后 端 相同 的 Pod 上 。 


在 默认 情况 下 ，Kubernetes 采 用 RoundRobin 模 式 进 行路 由 选择 ， 
但 我 们 也 可 以 通过 将 service.spec.sessionAffinity 设 置 为 “ClientIP” 来 启用 
SessionAffinity 策 略 ， 这 样 ， 同 一 个 客户 端 发 来 的 请 求 束 会 建立 一 个 
Session， 并 且 对 应 到 后 端 固定 的 某 个 Pod 上 了 ° 


在 某 些 应 用 场景 中 ， 开 发 人 员 和 希望 自己 控制 负载 均衡 的 策略 ， 不 
使 用 Service 提 供 的 默认 负载 均衡 的 功能 ，Kubernetes 通 过 Headless 
Service 的 概念 来 实现 这 种 功能 ， 即 不 给 Service 设 置 ClusterIP (无 入 口 
IP 地 址 ) ， 而 仅 通过 Label Selector 将 后 端的 Pod 列 表 返 回 给 调用 的 客户 
Jira o PAU: 


apiVersion: vi 

kind: Service 

metadata: 
name: nginx 
labels: 


app: nginx 


spec: 
ports: 
- port: 80 
clusterIP: None 
selector: 


app: nginx 


该 Service 没 有 虚拟 的 ClusterIP 地 址 ， 对 其 进行 访问 将 获得 具有 
Label“app=nginx” 的 全 部 Pod 列 表 ， 然 后 客户 端 程序 需要 实现 目 己 的 负 
载 分 发 策略 ， 再 确定 访问 具体 哪 一 个 后 端的 Pod 。 


在 某 些 环境 中 ， 应 用 系统 需要 将 一 个 外 部 数据 库 作 为 后 端 服务 进 
行 连接 ， 或 将 另 一 个 集群 或 Namespace 中 的 服务 作为 服务 的 后 端 ， 这 
时 可 以 通过 创建 一 个 无 Label Selector 的 Service 来 实现 : 


kind: Service 
apiVersion: v1 
metadata: 

name: my-service 
spec: 

ports: 

- protocol: TCP 

port: 80 


targetPort: 80 


通过 该 定义 创建 的 是 一 个 不 带 标 签 选 择 器 的 Service， 即 无 法 选择 
后 端的 Pod， 系 统 不 会 目 动 创 建 Endpoint， 因 此 需要 手动 创建 一 个 和 该 


Service 同 名 的 Endpoint， 用 于 指 癌 实际 的 后 端 访问 地 址 。 创 建 Endpoint 
的 配置 文件 内 容 如 下 : 


kind: Endpoints 
apiVersion: v1 
metadata: 
name: my-service 
subsets: 
- addresses: 
- IP: 1.2.3.4 
ports: 


- port: 80 


al AI216 RAS, W iA PN Se TE ae HY Service All E A PREE A 
的 Service 一 样 ， 请 求 将 会 被 路 由 到 由 用 户 手 动 定义 的 后 端 Endpoint 
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图 2.16 ”Service 指 向 外 部 服务 


有 了 时， 一 个 容 右 应 用 也 可 能 提供 多 个 端口 的 服务 ， 所 以 在 Service 
的 定义 中 也 可 以 相应 地 设置 为 多 个 端口 。 在 下 面 的 例 于 中 ，Service 设 
置 了 两 个 端口 号 ， 并 且 为 每 个 端口 号 进行 了 命名 : 


apiVersion: v1 
kind: Service 
metadata: 

name: webapp 

spec: 

ports: 

- port: 8080 
targetPort: 8080 
name: web 

- port: 8005 
targetPort: 8005 
name: management 

selector: 


app: webapp 


另 一 个 例子 是 两 个 端口 号 使 用 了 不 同 的 4 层 协议 ， 即 TCP 或 UDP: 


apiVersion: v1 

kind: Service 

metadata: 
name: kube-dns 
namespace: kube-system 


labels: 


k8s-app: kube-dns 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 


clusterIP: 169.169.0.100 


ports: 
- name: dns 
port: 53 


protocol: UDP 
- name: dns-tcp 
port: 53 


protocol: TCP 


2.5.3 ”集群 外 部 访问 Pod 或 Service 


由 于 Pod 和 Service 是 Kubernetes 集 群 范 围 内 的 虚拟 概念 ， 所 以 集群 
AEE "f Ji Ae St CIA Hw Pod AIP HHL BY ServiceB] He TU TP HE AN BEF 
端口 号 访问 到 它们 。 为 了 让 外 部 客户 端 可 以 访问 这 些 服务 ， 可 以 将 
ieee LIS BAS BI fg EDL, MEA ig DA Be A EL 
理 机 访问 容器 应 用 。 


1. 将 容 句 应 用 的 端口 号 映射 到 物理 机 


(1) 通过 设置 容器 级 别 的 hostPort， 将 容器 应 用 的 端口 号 映射 到 
物理 机 上 : 


pod-hostport.yaml 
apiVersion: vi 
kind: Pod 
metadata: 

name: webapp 

labels: 

app: webapp 

spec: 

containers: 

- name: webapp 


image: tomcat 


ports: 
- containerPort: 8080 


hostPort: 8081 
通过 kubectl create fig & 8l] 5X Pod: 


# kubectl create -f pod-hostport.yaml 


pod "webapp" created 


38 1T LA TP SE 40180812 L1 57 i RI Pod NW Aas ARS : 


# curl 192.168.18.3:8081 
<!DOCTYPE html» 
«html lang="en"> 
«head» 
«meta charset-"UTF-8" /» 


<title>Apache Tomcat/8.0.35</title> 


(2) 通过 设置 Pod 级 别 的 hostNetwork=true， 该 Pod 中 所 有 容器 的 
端口 号 都 将 被 直接 映射 到 物理 机 上 。 设 置 hostNetwork=true 时 需要 注 
意 ， 在 容器 的 ports 定 义 部 分 如 果 不 指定 hostPort， 则 默认 hostPort 等 于 
containerPort， 如 果 指 定 了 hostPort， 则 hostPort 必 须 等 于 containerPort 的 


值 。 


pod-hostnetwork.yaml 


apiVersion: v1 


kind: Pod 
metadata: 

name: webapp 

labels: 
app: webapp 

spec: 

hostNetwork: true 

containers: 

- name: webapp 
image: tomcat 
imagePullPolicy: Never 
ports: 


- containerPort: 8080 
创建 这 个 Pod: 


# kubectl create -f pod-hostnetwork.yaml 


pod "webapp" created 


38 1E] LA TP HE 4018080? L1 57 i RI Pod AI EA Aas ARS : 


# curl 192.168.18.4:8080 
<!DOCTYPE html» 
«html lang="en"> 


«head» 


«meta charset="UTF-8" /» 


<title>Apache Tomcat/8.0.35</title> 


2. 将 Service 的 端口 号 映射 到 物理 机 


(1) 通过 设置 nodePort 映 射 到 物理 机 ， 同 时 设置 Service 的 类 型 为 
NodePort: 


apiVersion: vi 
kind: Service 
metadata: 

name: webapp 

spec: 

type: NodePort 

ports: 

- port: 8080 
targetPort: 8080 
nodePort: 8081 

selector: 


app: webapp 


创建 这 个 Service: 


# kubectl create -f webapp-svc-nodeport.yaml 
You have exposed your service on an external port on 
all nodes in your 


cluster. If you want to expose this service to the 


external internet, you may 


need to set up firewall rules for the service port(s) 


(tcp:8081) to serve traffic. 


See http://releases.k8s.io/release-1.3/docs/user- 
guide/services-firewalls.md for more details. 


service "webapp" created 


系统 提示 信息 说 明 : 由 于 要 使 用 物理 机 的 端口 号 ， 所 以 需要 在 防 
火 墙 上 做 好 相应 的 配置 ， 以 使 得 外 部 客户 端 能 够 访问 到 该 端口 。 


通过 物理 机 的 IP 地 址 和 nodePort 8081 端 口号 访问 服务 : 


# curl 192.168.18.3:8081 
<!DOCTYPE html» 
«html lang="en"> 
<head> 
<meta charset="UTF-8" /> 


<title>Apache Tomcat/8.0.35</title> 


同样 ， 对 该 Service 的 访问 也 将 被 负载 分 发 到 后 端的 多 个 Pod 上 。 


(2) 通过 设置 LoadBalancer 映 射 到 云 服务 商 提供 的 LoadBalancer 
地 址 。 这 种 用 法 仅 用 于 在 公有 云 服 务 提 供 商 的 云 平 台 上 设置 Service 的 
场景 。 在 下 面 的 例子 中 ， status.loadBalanceringress.ip ix i 的 
146.148.47.155 为 云 服务 商 提 供 的 负载 均衡 器 的 IP 地 址 。 对 该 Service 的 


访问 请 求 将 会 通过 LoadBalancer 转 发 到 后 端 Pod 上 ， 负 载 分 发 的 实现 方 
式 则 依赖 于 云 服 务 商 提供 的 LoadBalancer 的 实现 机 制 。 


kind: Service 
apiVersion: v1 
metadata: 


name: my-service 


spec: 
selector: 
app: MyApp 
ports: 


- protocol: TCP 
port: 80 
targetPort: 9376 
nodePort: 30061 
ClusterIP: 10.0.171.239 
loadBalancerIP: 78.11.24.19 
type: LoadBalancer 
status: 
loadBalancer: 
ingress: 


- ip: 146.148.47.155 


2.5.4 DNS 服务 搭建 指南 


根据 第 1 草 对 Service 概 念 的 说 明 ， 为 了 能 够 通过 服务 的 名 字 在 集群 
内 部 进行 服务 的 相互 访问 ， 需 要 创建 一 个 虚拟 的 DNS 服务 来 完成 服务 
名 到 ClusterIP 的 解析 。 本 节 将 对 如 何 搭建 DNS 服 务 进行 详细 说 明 。 


Kubemetes 提 供 的 虚拟 DNS 服 务 名 为 skydns， 由 四 个 组 件 组 成 。 
(1) etcd: DNS 存储 。 


(2) kube2sky: 将 Kubernetes Master 中 的 Service (服务 ) 注册 到 
etcd ° 


(3) skyDNS: 提供 DNS 域名 解析 服务 。 
(4) healthz: 提供 对 skydns 服 务 的 健康 检查 功能 o 


图 2.17 描 述 了 KubernetesDNS 服 务 的 总 体 架 构 。 
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[42.17  Kubernetes DNS 服务 的 总 体 架 构 


1.skydns 配 置 文件 说 明 


skydns 服 务 由 一 个 RC 和 一 个 Service 的 定义 组 成 ,分别 由 配置 文件 
skydns-rc.yaml 和 skydns-svc.yaml 定 义 。 


skydns 的 RC 配置 文件 skydns-rc.yaml 的 内 容 如 下 ， 包 含 了 4 个 容器 
的 定义 : 


skydns-rc.yaml 

apiVersion: v1 

kind: ReplicationController 
metadata: 


name: kube-dns-v11 


namespace: kube-system 
labels: 
k8s-app: kube-dns 
version: v11 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: kube-dns 
version: vit 
template: 
metadata: 
labels: 
k8s-app: kube-dns 
version: v11 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: etcd 
image: gcr.io/google containers/etcd- 
amd64:2.2.1 
resources: 
limits: 
cpu: 100m 
memory: 50Mi 
requests: 


cpu: 100m 


memory: 50Mi 
command: 
- /usr/local/bin/etcd 
- -data-dir 
- /tmp/data 
- -listen-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -advertise-client-urls 
- http://127.0.0.1:2379,http://127.0.0.1:4001 
- -initial-cluster-token 
- skydns-etcd 
volumeMounts: 
- name: etcd-storage 
mountPath: /tmp/data 
- name: kube2sky 
image: gcr.io/google containers/kube2sky- 
amd64:1.15 
resources: 
limits: 
cpu: 100m 
# Kube2sky watches all pods. 
memory: 50Mi 
requests: 
cpu: 100m 
memory: 50Mi 
livenessProbe: 


httpGet: 


path: /healthz 
port: 8080 
scheme: HTTP 
initialDelaySeconds: 60 
timeoutSeconds: 5 
successThreshold: 1 
failureThreshold: 5 
readinessProbe: 
httpGet: 
path: /readiness 
port: 8081 
scheme: HTTP 
# we poll on pod startup for the Kubernetes 
master service and 
# only setup the /readiness HTTP server once 
that's available. 
initialDelaySeconds: 30 
timeoutSeconds: 5 
args: 
# command = "/kube2sky" 
- --kube-master-url-http://192.168.18.3:8080 
- --domain=cluster.local 
- name: skydns 
image: gcr.io/google containers/skydns:2015- 
10-13-8c72f8c 
resources: 


limits: 


cpu: 100m 
memory: 50Mi 
requests: 
cpu: 100m 
memory: 50Mi 
args: 


# command = "/skydns" 


-machines=http://127.0.0.1:4001 
-addr=0.0.0.0:53 


-ns-rotate=false 


-domain=cluster.local 


ports: 

- containerPort: 53 
name: dns 
protocol: UDP 

- containerPort: 53 
name: dns-tcp 
protocol: TCP 


- name: healthz 


gcr.io/google containers/exechealthz:1.0 
resources: 
# keep request = limit to 
container in guaranteed class 
limits: 
cpu: 10m 


memory: 20Mi 


image: 


keep this 


requests: 
cpu: 10m 
memory: 20Mi 
args: 
- -cmd=nslookup 
kubernetes.default.svc.cluster.local 127.0.0.1 >/dev/null 
- -port-8080 
ports: 
- containerPort: 8080 
protocol: TCP 
volumes: 
- name: etcd-storage 
emptyDir: {} 
dnsPolicy: Default # Don't use cluster DNS. 


需要 修改 的 几 个 配置 参数 如 下 。 


(1) kube2sky% #8 fa 22 |H] Kubernetes Master, ， 需 要 配置 Master 
Are Se LIP HOLE Ag OS, AN rix EAXC-kube master urlii*j 
{A Ahttp://192.168.18.3: 8080 ° 


(2) kube2sky 容 器 和 skydns 容 器 的 启动 参数 --domain x E 
Kubernetes 集 群 中 Service 所 属 的 域名 ， 本 例 中 为 “cluster.local”。 JE 2] 
后 ，kube2sky 会 通过 API Server 监 控 集 群 中 全 部 Service 的 定义 ， 生 成 相 
应 的 记录 并 保存 到 etcd 中 。kube2sky 为 每 个 Service 生 成 以 下 两 条 记录 。 


. «service name».«namespace name-».«domain» i: 


° <service_name>.<namespace_name>.svc.<domain> EN 


(3) skydns 的 启动 参数 -addr=0.0.0.0: 53 表 示 使 用 本 机 TCP 和 
UDP 的 53 端 口 提供 服务 。 


skydns 的 Service 配 置 文件 skydns-svc.yaml 的 内 容 如 下 : 


skydns-svc.yaml 
apiVersion: vi 
kind: Service 
metadata: 
name: kube-dns 
namespace: kube-system 
labels: 
k8s-app: kube-dns 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "KubeDNS" 
spec: 
selector: 
k8s-app: kube-dns 


clusterIP: 169.169.0.100 


ports: 
- name: dns 
port: 53 


protocol: UDP 
- name: dns-tcp 
port: 53 


protocol: TCP 


注意 ，skydns 服 务 使 用 的 clusterIP 需 要 我 们 指定 一 个 国定 的 卫 地 
址 ， 每 个 Node 的 kubelet 进程 都 将 使 用 这 个 卫 地 址 ， 不 能 通过 
Kubernetes 上 自动 分 配 。 


另外 ， 这 个 下地 址 需要 在 kube-apiserver 启 动 参数 --service-cluster- 
ip-range 指 定 的 卫 地 址 范围 内 。 


在 创建 skydns 容 右 之 前 ， 先 修改 每 个 Node 上 kubelet 的 启动 参数 。 


2. 修 改 每 台 Node 上 的 kubelet 启 动 参数 
修改 每 台 Node 上 kubelet 的 启动 参数 ， 加 上 以 下 两 个 参数 。 


e --cluster_dns=169.169.0.100: 为 DNS 服 务 的 ClusterIP 地 址 。 
e --cluster_domain=cluster.local: 为 DNS 服 务 中 设置 的 域名 。 


然后 重启 kubelet 服 务 。 


3. 创 建 skydnsRC 和 Service 


通过 kubectl create 完 成 skydns 的 RC 和 Service 的 创建 : 


#kubectl create -f skydns-rc.yaml 


#kubectl create -f skydns-svc.yaml 


查看 RC、Pod 和 Service， 确 保 容器 成 功 启动 : 


# kubectl get rc --namespace=kube-system 


NAME DESIRED 


CURRENT AGE 


kube-dns-vi1 1 1 
1d 
# kubectl get pods --namespace-kube-system 
NAME READY 
STATUS RESTARTS AGE 
kube-dns-vi1-6diwu 4/4 
Running 0 1d 
# kubectl get services --namespace=kube-system 
NAME CLUSTER- IP EXTERNAL - IP 
PORT(S) AGE 
kube-dns 169.169.0.100 <none> 


53/UDP, 53/TCP 1d 


然后 ， 我 们 为 redis-master 应 用 创建 一 个 Service: 


redis-master-service.yaml 


apiVersion: vi 
kind: Service 
metadata: 
name: redis-master 
labels: 
name: redis-master 


spec: 


ports: 

- port: 6379 
targetPort: 6379 

selector: 


name: redis-master 


查看 创建 好 的 redis-master service: 


# kubectl get services 
NAME 
PORT(S) AGE 
redis-master 


6379/TCP 1h 


CLUSTER-IP EXTERNAL - IP 


169.169.8.10 <none> 


可 以 看 到 ， 系 统 为 redis-master 服 务 分 配 了 一 个 虚拟 IP 地 址 : 


169.169.8.10 ° 


到 此 ， 在 Kubermetes 集 群 内 的 虚拟 DNS 服 务 就 搭建 好 了 。 在 需 


访问 redis-master 的 应 用 中 ， 仅 需要 配置 上 redis-master Service 的 名 称 和 
服务 的 端口 号 ， 惑 能够 访问 到 redis-master 应 用 了 ， 让 我 们 回顾 一 下 
redis-slave 应 用 需要 访问 redis-master 的 配置 内 容 : 


redis-slave 镜 像 的 启动 脚本 /run.sh 的 内 容 为 : 


if [[ ${GET_HOSTS_FROM: -dns} == "env" ]]; then 


redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 


6379 


else 


redis-server --slaveof redis-master 6379 


fi 


在 使 用 DNS 模式 的 情况 下 ，redis-slave 配 置 的 Master 地 址 为 : redis- 
master: 6379。 通 过 服务 名 进行 配置 ， 能 够 极 大 地 人 徐 化 客户 端 应 用 对 
后 端 服务 变化 的 感知 ， 包 括 服务 虚拟 耻 地 址 的 变化 、 服 务 后 端 Pod 的 变 
化 等 ， 对 应 用 程序 的 微服 务 架 构 实现 提供 了 强 有 力 的 支撑 。 


4. 通 过 DNS 查找 Service 


接 下 来 使 用 一 个 融 有 nslookup 工 具 的 Pod 来 验证 DNS 服务 是 否 能 够 
正常 工作 : 


busybox.yaml 


apiVersion: v1 
kind: Pod 
metadata: 

name: busybox 

namespace: default 

spec: 

containers: 

- name: busybox 
image: gcr.io/google containers/busybox 
command: 

- sleep 


= "2600" 


运行 kubectl create-f busybox.yaml 完 成 创建 


在 该 容器 成 功 启动 后 ， 过 kubectl exec<container_id>nslookupi# 
行 测 试 : 
# kubectl exec busybox -- nslookup redis-master 
Server: 169.169.0.100 


Address 1: 169.169.0.100 


Name : redis-master 


Address 1: 169.169.8.10 


可 以 看 到 ， 通 过 DNS 服务 器 169.169.0.100 成 功 找到 了 名 为 “redis- 
master” 服 务 的 IP 地 址 : 169.169.8.10 ° 


如 果 某 个 Service 属 于 不 同 的 命名 空间 ， 那 么 在 进行 Service 碍 找 
时 ， 需 要 带 上 namespace 的 名 字 。 下 面 以 查找 kube-dns 服 务 为 例 : 


# kubectl exec busybox -- nslookup kube-dns.kube- 
system 
server: 169.169.0.100 


Address 1: 169.169.0.100 


Name: kube-dns.kube-system 


Address 1: 169.169.0.100 


如 果 仅 使 用 "kube-dns” 来 进行 查找 ， 则 将 会 失败 : 


nslookup: can't resolve 'kube-dns' 


5.DNS 服 务 的 工作 原理 解析 
让 我 们 看 看 DNS 服 务 背 后 的 工作 原理 。 


(1) kube2sky 容 器 应 用 通过 调用 Kubernetes Master 的 API 获 得 集群 
中 所 有 Service 的 信息 ， 并 持续 监控 新 Service 的 生成 ， 然 后 写 入 etcd 
中 o 


查看 etcd 中 存储 的 Service 信 息 : 


# kubectl exec kube-dns-v8-5tpm2 -c etcd -- 
namespace-kube-system etcdctl ls /skydns/local/cluster 
/skydns/local/cluster/default 
/skydns/local/cluster/svc 


/skydns/local/cluster/kube-system 


可 以 看 到 在 skydns 键 下 面 ， 根 据 我 们 配置 的 域名 (cluster.local) 
生成 了 localcluster 子 键 ， 接 下 来 是 namespace (defaultfllkube-system) 
和 svc 〈 下 面 也 按 namespace 生 成 子 键 ) 。 


查看 redis-master 服 务 对 应 的 键 值 : 


# kubectl exec kube-dns-v8-5tpm2 -c etcd -- 
namespace=kube- system etcdctl get 


/skydns/local/cluster/default/redis-master 


("host":"169.169.8.10", "priority":10, "weight":10,"ttl":30," 


targetstrip":0) 


可 以 看 到 , redis-master 服务 对 应 的 完整 域名 为 redis- 
master.default.cluster.local, Jf H LIPHH HEA 169.169.8.10 ° 


(2) 根据 kubelet 启 动 参数 的 设置 (--cluster_dns) ，kubelet 会 在 
个 新 创 建 鸭 Pod 中 设置 DNS 域名 解析 配置 文件 /etc/resolv.conf 文 件 ， 
在 其 中 增加 了 一 条 nameserver 配 置 和 一 条 search 配 置 : 


nameserver 169.169.0.100 
search default.svc.cluster.local svc.cluster.local 


cluster.local localdomain 


WHI A FARA as 169.169.0.10017 [ER] Sz. Ent A skydnstE537m H E 
提供 的 DNS 解析 服务 。 


(3) 最 后 ， 应 用 程序 就 能 够 像 访问 网 站 域名 一 样 ， 仅 仅 通过 服务 
的 名 子 就 能 访问 到 服务 了 。 


仍然 以 redis-slave 为 例 ， 假 设 已 经 启动 了 redis-slave Pod, “5 
redis-slave 容 絮 进 行 查 看 ， 可 以 看 到 其 通过 DNS 域 名 服务 找到 了 redis- 
master 的 IP 地 址 169.169.8.10， 并 成 功 建立 了 连接 。 


2.5.5 Ingress: HTTP 7 层 路 由 机 制 


根据 前 面 对 Service 的 使 用 说 明 ， 我 们 知道 Service 的 表现 形式 为 
IP: Port， 即 工作 在 TCP/IP 层 。 而 对 于 基于 HTTP 的 服务 来 说 ， 不 同 的 
URL 地 址 经 常 对 应 到 不 同 的 后 端 服 务 或 者 虚拟 服务 器 (Virtual 
Host) ， 这 些 应 用 层 的 转发 机 制 仅 通过 Kubernetes 的 Service 机 制 是 无 法 
实现 的 。Kubernetes v1.1 版 本 中 新 增 的 Ingress 将 不 同 URL 的 访问 请 求 转 
发 到 后 端 不 同 的 Service， 实 现 HITP 层 的 业务 路 由 机 制 。 在 Kubernetes 
集群 中 ，Ingress 的 实现 需要 通过 Ingress 的 定义 与 Ingress Controller 的 定 
义 结合 起 来 ， 才 能 形成 完整 的 HTTP 人 负载 分 发 功能 。 


图 2.18 显 示 了 一 个 典型 HTTP 层 路 由 的 例子 。 


。 对 http://mywebsite.com/api 的 访问 将 被 路 由 到 后 端 名 为 “api” 的 
Service ° 

e 对 http://mywebsite.com/web 的 访问 将 被 路 由 到 后 端 名 为 “web” 的 
Service ° 

e 对 http://mywebsite.com/doc 的 访问 将 被 路 由 到 后 端 名 为 “doc” 的 


Service ° 


service: 
http://docs:80 


service: 
http://web:80 


service: 
http://api:80 


api | | web | | docs 


图 2.18  Ingresszr {il 


1.8] Ingress Controller 


TEE XN Ingress Hj, ma Zeik Ingress Controller， 以 实现 为 所 有 
后 端 Service 提 供 一 个 统一 的 入 口 。Ingress Controller 需 要 实现 基于 不 同 
HTTP URL 向 后 转发 的 负载 分 s 通常 应 该 根据 应 用 系统 的 需求 
进行 个 性 化 实现 。 如 果 公 有 云 服务 商 能 够 提供 该 类 型 的 HITP 路 由 
LoadBalancer， 则 oe a Controller ° 


4 


f£ Kubernetes 中 Ingress Controller 将 以 Pod 的 形式 运行 ， 监 控 
apiserver 的 /ingress $% O ( 在 13 版 本 m 
为 lapis/extensions/v1betal/namespaces/«namespace name-/ingresses #2 
L1) Jmm HJ backend services, 4] È service x ^E Æ (f, J) Ingress 
Controller 应 目 动 更 新 其 转发 规则 e 


在 下 面 的 例子 中 ， 我 们 使 用 Nginx 来 实现 一 个 mgress Controller, 
需要 实现 的 基本 逻辑 如 下 。 


(1) 监听 apiserver， 获 取 全 部 ingress 的 定义 。 


(2) 基于 ingress 的 定义 ， 生 成 Nginx 所 需 的 配置 文 


件 /etc/nginx/nginx.conf ° 


(3) 执行 nginx-s reload 命 令 ， 重 新 加 载 nginx.conf 配 置 文 件 的 内 


Dm 


基于 Go 语言 的 代码 实现 如 下 : 


for { 
rateLimiter.Accept() 
ingresses, err :二 
ingClient.List(labels.Everything(), fields.Everything()) 
if err ! = nil | | 


reflect .DeepEqual(ingresses.Items, known.Items) { 


continue 
} 
if w, err := os.Create("/etc/nginx/nginx.conf"); 
err != nil { 
log.Fatalf("Failed to open %v: %v", nginxConf, 
err) 
} else if err := tmpl.Execute(w, ingresses); err 
I- nil { 


log.Fatalf("Failed to write template %v", err) 


} 
shellOut("nginx -s reload") 


我 们 可 以 通过 直接 下 载 谷歌 提供 的 nginx-ingress 镜 像 来 创建 Ingress 


Controller: 


nginx-ingress-rc.yaml 
apiVersion: vi 
kind: ReplicationController 
metadata: 
name: nginx-ingress 
labels: 
app: nginx-ingress 
spec: 
replicas: 1 
selector: 
app: nginx-ingress 
template: 
metadata: 
labels: 
app: nginx-ingress 
spec: 
containers: 
- image: gcr.io/google containers/nginx- 
ingress:0.1 


name: nginx 


ports: 
- containerPort: 80 


hostPort: 80 


这 里 ， 该 Nginx 应 用 设置 了 hostPort， 即 它 将 容器 应 用 监听 的 80 端 
口号 映射 到 物理 机 ， 以 使 得 客户 端 应 用 可 以 通过 URL 地 址 “http:/ 物 理 
机 IP: 80” 来 访问 该 Ingress Controller ° 


通过 kubectl create 命 令 创 建 该 RC: 


# kubectl create -f nginx-ingress-rc.yaml 


replicationcontroller "nginx-ingress" created 


# kubectl get pods 


NAME READY STATUS RESTARTS 
AGE 


nginx-ingress-mrwtz 1/1 Running 0 


2S 


2. 定 义 Ingress 
为 mywebsite.com 定 义 Imgress， 设 置 到 后 端 Service 的 转发 规则 : 


apiVersion: extensions/vibetal 
kind: Ingress 
metadata: 


name: mywebsite-ingress 


spec: 
rules: 


- host: mywebsite.com 


http: 
paths: 
- path: /web 
backend: 


serviceName: webapp 


servicePort: 80 


这 个 Ingress 的 定义 说 明 对 目标 URL http://mywebsite.com/web B5] Jj 
问 将 被 转发 到 Kubermetes 的 一 个 Service E: webapp: 80。 


创建 该 Ingress: 


# kubectl create -f ingress.yaml 


ingress "mywebsite-ingress" created 


# kubectl get ingress 
NAME HOSTS ADDRESS PORTS 
AGE 
mywebsite-ingress mywebsite.com 80 


17s 


在 该 Ingress 成 功 创建 后 ， 登 录 nginx-ingress Pod， 查 看 其 自动 生成 
的 nginx.conf 配 置 文件 内 容 : 


events { 


worker_connections 1024; 


} 
http { 
server { 
listen 80; 
server_name mywebsite.com; 4 Ingress 中 定义 的 虚拟 
host% 
resolver 127.0.0.1; 
location /web { # Ingress 中 定义 的 路 
径 /web 
proxy pass http://webapp; # service% 
1 
} 
} 


3.7 A)http://mywebsite.com/web 


H T Ingress Controller 设 置 了 hostPort， 所 以 我 们 可 以 通过 其 所 在 
的 物理 机 对 其 进行 访问 。 可 以 在 物理 机 上 设置 mywebsite.com 对 应 的 IP 
地 址 ， 也 可 以 通过 curl--resolve 进 行 指定 : 


$ curl --resolve mywebsite.com:80:192.168.18.3 


mywebsite.com/foo 


将 获得 Kubernetes Service*webapp: 80” 提 供 的 主页 。 


4.Ingress 的 发 展 路 线 


当前 UMEN 在 Kubernetes 的 后 续 版 本 中 将 增加 至 
少 以 下 功能 


。 文 持 更 多 TLS 选 项 ， 例 如 SNI、 重 加 密 等 。 

。 文 持 L4 和 L7 人 负载 均衡 策略 (目前 只 支持 HTTP 层 的 规则 ) e 

。 文 持 更 多 的 转发 规则 (目前 仅 支持 基于 URL 路 径 的 )  ， 例 如 重 定 
向 规则 、 会 话 保持 规则 等 。 


"Bag Kubernetes 核 心 原理 


本 章 对 Kubermnetes 的 核心 原理 进行 深入 分 析 ， 首 先 从 API Server 的 
访问 开始 讲 起 ， 然 后 分 析 Master 玉 点 上 Controller Manager 各 个 组 件 的 
功能 实现 ， 以 及 Scheduler 预 选 算法 和 优选 算法 。 接 下 来 讲解 Node 广 点 
上 的 kubelet 和 kube-proxy 组 件 的 运行 机 制 。 最 后 ， 深 入 分 析 安 全 机 制 
和 网 络 原理 。 


3.1 Kubernetes API Server £8 47 AT 


eU EH 


总 体 来 看 ，Kubernetes API Server 的 核心 功能 是 提供 了 Kubernetes 
各 类 资源 对 象 (如 Pod、RC、Service 等 ) 的 增 、 删 、 改 、 查 及 Watch 等 
HTTPRest 接 口 ， 成 为 集群 内 各 个 功能 模块 之 间 数 据 交 互 和 通信 的 中 心 
枢纽 ， 是 整个 系统 的 数据 总 线 和 数据 中 心 。 除 此 之 外 ， 它 还 有 以 下 一 
些 功 能 特性 。 


(1) 是 集群 管理 的 API 入 口 。 
(2) 是 资源 配额 控制 的 入 口 。 
(3) 提供 了 完备 的 集群 安全 机 制 。 


3.1.1 Kubernetes API Server 概 二 


Kubernetes API Server 通 过 一 个 名 为 kube-apiserver 的 进程 提供 服 
务 ， 该 进程 运行 在 Master 世 点 上 。 在 默认 情况 下 ，kube-apiserver 进 程 
在 本 机 的 8080 端 口 (对 应 参数 --insecure-port) 提供 REST 服 务 。 我 们 可 
以 同时 启动 HITPS 安 全 端口 (--secure-port=6443) 来 启动 安全 机 制 ， 
加 强 REST API 访 问 的 安全 性 。 


通常 我 们 可 以 通过 命令 行 工 具 kubectl 来 与 Kubernetes API Server% 
互 ， 它 们 之 间 的 接口 是 REST 调 用 。 为 了 测试 和 学 习 Kubernetes API 
Server 所 提供 的 接口 ， 我 们 也 可 以 使 用 curl 命 令 行 工 具 进 行 快速 验证 。 


比如 ， 我 们 登录 Master 节 点， 运行 下 面 的 cu 命令， 得 到 以 JSON 
方式 返回 的 Kubernetes API 的 版 本 信息 : 


# curl localhost:8080/api 
1 
"kind": "APIVersions", 
"versions": [ 
"yq" 
], 
"serverAddressByClientCIDRs": [ 
{ 
"ClientCIDR": "0.0.0.0/0", 
"serverAddress": "192.168.18.131:6443" 


可 以 运行 下 面 的 命令 ， 来 查看 Kubernetes API Server 目 前 所 文 持 的 
资源 对 象 的 种 类 : 


# curl localhost:8080/api/v1 


根据 以 上 命令 的 输出 ， 我 们 可 以 运行 下 面 的 cu 命令 ， 分 别 返 回 
集群 中 的 Pod 列 表 、Service 列 表 、RC 列 表 等 : 


# curl localhost:8080/api/v1/pods 
# curl localhost:8080/api/v1/services 


# curl localhost:8080/api/vi/replicationcontrollers 


如 果 我 们 只 想 对 外 又 露 部 分 REST 服 务 ， 则 可 以 在 Master 或 其 他 任 
何 世 点 上 通过 运行 kubectl proxy 进 程 局 动 一 个 内 部 代理 来 实现 。 


一 


运行 下 面 的 命令 ， 我 们 在 8001 端 口 启动 代理 ， 并 且 拒 绝 客户 端 访 
问 RC 的 API: 


# kubectl proxy --reject- 
paths="4/api/vi/replicationcontrollers" --port=8001 --v-2 


Starting to serve on 127.0.0.1:8001 


运行 下 面 的 命令 进行 验证 : 


# curl localhost:8001/api/vi/replicationcontrollers 


<h3>Unauthorized</h3> 


kubectl proxy 具 有 很 多 特性 ， 最 实用 的 一 个 特性 是 提供 简单 有 效 的 
安全 机 制 ， 比 如 采用 白 名 单 来 限制 非法 客户 端 访问 时 ， 只 要 增加 下 面 
这 个 参数 即 可 : 


- accept -hosts-"^localhost$,^127NN.0NN.0NN. 1$, ^NN 
[::1NN]S$" 


最 后 一 种 方式 是 通过 编程 的 方式 调用 Kubernetes API Server » E ff 
使 用 场景 又 细 分 为 以 下 两 种 。 


第 1 种 使 用 场景 : 运行 在 Pod 里 的 用 户 进 程 调用 Kubernetes API， 通 
常用 来 实现 分 布 式 集群 搭建 的 目标 。 比 如 下 面 这 段 来 自 谷 歌 官方 的 
Elastic Search 集 群 例子 中 的 代码 ，Pod 在 启动 的 过 程 中 通过 访问 
Endpoints 的 API， 找 到 属于 elasticsearch-logging 这 个 Service 的 所 有 Pod 
副本 的 IP 地 址 ， 用 来 构建 集群 ， 如 图 3.1 所 示 。 


等 待 5 分 钟 获取 集群 里 其 他 节点 的 地 址 信息 
2. : > 并 输出 到 控制 台 ， 随 后 被 写 入 elasticsearch 的 
ERR 1 配置 文件 里 


t Now(); time.S (t) 5*ti M ti ( time.Second) 2 
dpoints, err = (api. paceSyst ("elasticsearch-logging") 
nil { 
continue 
addrs = flattenSubsets(endpoints.Subsets) glog.Infof("Endpoints = Ws", addrs) 
glog.Infof("Found Xs", addrs) fmt.Printf("discovery.zen.ping.unicast.hosts: [Xs]Wn", strings.Join(addrs, ", ")) 
if (addrs) && le dd == count ( 
break 来 自 镜像 中 的 容器 启动 脚本 


图 3.1 应 用 程序 编程 访问 API Server 


在 上 述 使 用 场景 中 ，Pod 中 的 进程 如 何 知道 API Server 的 访问 地 址 
We? 答案 很 简单 ， 因 为 Kubernetes API Server 本 身 也 是 一 个 Service， 它 
的 名 字 吏 是 “kubernetes”， 并 且 它 的 Cluster IP 地 址 是 Cluster IPH HENE E 
的 第 1 个 地 址 ! 另外 ， 口 是 HTTPS 端 口 443， 通 过 kubectl 
get service 命 令 可 以 确认 这 一 


# kubectl get service 
NAME CLUSTER-IP EXTERNAL - IP PORT(S) 
AGE 
kubernetes 169.169.0.1 <none> 443/TCP 
30d 


第 2 种 使 用 场景 : 开发 基于 Kubernetes 的 管理 平台 。 比 如 调用 
Kubernetes API 来 完成 Pod、Service、RC 等 资源 对 象 的 图 形 化 创建 和 管 
理 界面 ， 此 时 可 以 使 用 Kubernetes 及 各 开源 社区 为 开发 人 员 提 供 的 各 
种 语言 版 本 的 Client Library。 我 们 会 在 后 面 介绍 通过 编程 方式 访问 API 
Server 的 一 些 细 廊 技术 。 


3.1.2 ”独特 的 Kubernetes Proxy API 接 口 


前 面 我 们 说 过 ，Kubernetes API Server 最 主要 的 REST 接 口 是 资源 
对 象 的 增 、 删 、 改 、 碍 ， 除 此 之 外 ， 它 还 提供 了 一 类 很 特殊 的 REST 接 
口 Kubernetes Proxy API 接 口 ， 这 类 接口 的 作用 是 代理 REST 请 求 ， 
即 Kubernetes API Server 把 收 到 的 REST 请 求 转 发 到 某 个 Node 上 的 
kubelet 守 护 进 程 的 REST 端 口上 ， 由 该 Kubelet 进 程 负 责 响 应 。 


首先 ， 我 们 来 说 说 Kubernetes Proxy API 里 关于 Node 的 相关 接口 ， 
TX BEL AREST í% 7J/api/vl/proxy/nodes/(name) , XH! (name) JJ P m, 
的 名 称 或 1P 地 址 ， 包 括 以 下 几 个 具体 接口 : 


e /api/vl/proxy/nodes/{fname}/pods/，# 列 出 指定 节点 内 所 有 Pod 的 信 


A 
e /api/v1/proxy/nodes/{name}/stats/ #7 HH TRAE D RAHE RA 
计 信 息 


e /api/v1/proxy/nodes/{name}/spec/ ”# 列 出 指定 广 点 的 概要 信息 


例如 当前 Node 节 点 的 名 字 为 k8s-node-1， 用 下 面 的 命令 即 可 获取 
该 节点 上 所 有 运行 中 的 Pod: 


# curl localhost:8080/api/v1/proxy/nodes/k8s-node- 
1/pods 


需要 说 明 的 是 : 这 里 获取 的 Pod 的 信息 数据 来 目 Node 而 非 etcq 数 据 
库 ， 所 以 两 者 可 能 在 某 些 时 间 点 会 有 侦 兰 。 此 外 ， 如 有 果 kubelet 进 程 在 


JA oh IN E & --enable-debugging-handlers=true & 2% , — 35 人 Kubernetes 
Proxy API 还 会 增加 下 面 的 接口 : 


e /api/v1/proxy/nodes/{name }/run # 在 世 点 上 运行 某 个 容器 

e /api/v1/proxy/nodes/{name }/exec # 在 节点 上 的 某 个 容器 中 运 
行 某 条 命令 

e /api/v1/proxy/nodes/{name }/attach # T A E attach P A 


4a /api/v1/proxy/nodes/{name}/portForward #3 307 A EAI Podsiq 
口 转发 

e /api/v1/proxy/nodes/{name}/logs # 列 出 节点 的 各 类 日 志 
T, ffl UU tallylog 、lastlog、wtmp ^ ppp/ ^ rhsm/ ` audit/ ^ eU 


anaconda/ 4% 

e /api/v1/proxy/nodes/{name}/metrics # 列 出 和 该 节点 相关 的 Metrics 
信息 

e /api/v1/proxy/nodes/{name}/runningpods #7] HHT) AGA íT BAY 
Pod 信 息 


e /api/vl/proxy/nodes/{fnamej}/debug/pprof# 列 出 节点 内 当前 Web 服 务 
的 状态 ， 包 括 CPU 占 用 情况 和 内 存 使 用 情况 等 


接 下 来 ， 我 们 来 说 说 Kubernetes Proxy API 里 关于 Pod 的 相关 接 
口 ， 通 过 这 些 接口 ， 我 们 可 以 访问 Pod 里 某 个 容器 提供 的 服务 (如 
Tomcat 在 8080 端 口服 务 ) : 


e /api/v1/proxy/namespaces/{namespace}/pods/{name}/{path : *}# ij 
问 Pod 的 某 个 服务 接口 

e /api/v1/proxy/namespaces/{namespace}/pods/{name}  # 访 问 Pod 

e /api/v1/namespaces/{namespace}/pods/{name}/proxy/{path : *}# ij 
问 Pod 的 某 个 服务 接口 


e /api/v1/namespaces/{namespace}/pods/{name}/proxy  # 访 问 Pod 


在 上 面 的 4 个 接口 里 ， 后 面 两 个 接口 的 功能 与 前 面 两 个 完全 一 样 ， 
只 是 写法 不 同 。 下 面 我 们 用 第 1 章 的 Java Web 例 子 中 的 Tomcat Pod 来 说 
明 上 述 Proxy 接 口 的 用 法 。 


首先 ， 得 到 Pod 的 名 字 : 


# kubectl get pods 


NAME READY STATUS RESTARTS 
AGE 
mysql-c95jc 1/1 Running 0 
8d 
myweb-g9pmm 1/1 Running 0 
8d 


然后 ， 运 行 下 面 的 命令 ， 会 输出 Tomcat 的 首页 ， 即 相当 于 访问 
http://localhost: 8080/: 


# curl 
http://localhost:8080/api/v1/proxy/namespaces/default/pods/ 


myweb - g9pmm/ 


di Hi RT DAE DUI Pss "| jn] ETE, FEA Master D 53 AIP He, 
址 是 192.168.18.131 dX fl] E DJ i, as "P y A http://192.168.18.131 : 
8080/api/v1/proxy/namespaces/default/pods/myweb-g9pmm/ , Wè BE I Vj 
[Al Tomcat Ff 页 F 而 如 7 B 


A /api/v1/proxy/namespaces/default/pods/myweb-g9pmm/demo , Wè BE Vj 
问 Tomcat 中 Demo 应 用 的 页 面 了 。 


看 到 这 里 ， 你 可 能 明白 Pod 的 Proxy 接 口 的 作用 和 意义 了 : 在 
Kubernetes 集 群 之 外 访问 某 个 Pod 容 器 的 服务 (HTTP 服 务 ) 时 ， 可 以 
用 Proxy API 实 现 ， 这 种 场景 多 用 于 管理 目的 ， 比 如 逐一 排查 Service 的 
Pod 副 本 ， 检 查 哪些 Pod 的 服务 存在 异常 问题 。 


最 后 我 们 说 说 Service，Kubernetes Proxy API 也 有 Service 的 Proxy 接 
口 ， 其 接口 定义 与 Pod 的 接口 定义 基本 
FÉ: ee UE RR A e 比如， 我 
fl] #8 yi fe] myweb 3x ® Service ， 则 可 以 在 浏览 如 里 输入 
http://192.168.18.131 


8080/api/v 1/proxy/namespaces/default/services/myweb/demo/ ° 


3.13 ”集群 功能 模块 之 间 的 通信 


从 图 3.2 中 可 以 看 出 ，KubernetesAPI Server 作 为 集群 的 核心 ， 负 责 
集群 各 功能 模块 之 间 的 通信 。 集 群 内 的 各 个 功能 模块 通过 API Server} 
言 忌 存 入 etcd， 当 需要 获取 和 操作 这 些 数 据 时 ， 则 通过 API Server 提 供 
的 REST 接 口 (用 GET、LIST 或 WATCH 方 法 ) 来 实现 ， 从 而 实现 各 模 
块 之 间 的 信息 交互 。 


常见 的 一 个 交互 场景 是 kubelet 进 程 与 API Server 的 交互 。 每 个 
Node 世 点 上 的 kubelet 每 隔 一 个 时 间 周 期 ， 束 会 调用 一 次 API Server 的 
REST 接 口 报告 自身 状态 ，API Server 接 收 到 这 些 信息 后 ， 将 节点 状态 
言 息 更 新 到 etcd 中 。 此 外 ，kubelet 也 通过 API Server 的 Watch 接口 监听 
Pod 信 息 ， 如 果 监 听 到 新 的 Pod 副 本 被 调度 绑 定 到 本 节点 ， 则 执行 Pod 
对 应 的 容器 的 创建 和 启动 逻辑 ， 如 有 果 监 昕 到 Pod 对 象 被 删除 ， 则 删除 
本 节点 上 的 相应 的 Pod 容 需 ; 如 果 监 听 到 修改 Pod 信 息 ， 则 kubelet 监 听 
到 变化 后 ， 会 相应 地 修改 本 市 点 的 Pod 容 器 。 


/ Master 


API Server 


a ee m m | 


3.2 ”Kubernetes 结 构 


男 外 一 个 交互 场景 是 kube-controller-manager 进 程 与 API Server 的 交 
互 。kube-controller-manager 中 的 Node Controller 模 块 通过 API Severfe 
供 的 Watch 接 口 ， 实 时 监控 Node 的 信息 ， 并 做 相应 处 理 。 


还 有 一 个 比较 重要 的 交互 场景 是 kube-scheduler 与 API Server 的 交 
互 。 当 Scheduler 通 过 API Server 的 Watch 接口 监听 到 新 建 Pod 副 本 的 信 
县 后 ， 它 会 检索 所 有 符合 该 Pod 要 求 的 Node 列 表 ， 开 始 执行 Pod 调 度 膛 
辑 ， 调 度 成 功 后 将 Pod 绑 定 到 目标 节点 上 。 


为 了 绥 解 集群 各 模块 对 API Server 的 访问 压力 ， 各 功能 模块 都 采用 
绥 存 机 制 来 缓存 数据 。 各 功能 模块 定时 从 API Server 获 取 指 定 的 资源 对 
象 信息 (通过 LIST 及 WATCH 方 法 ) ， 然 后 将 这 些 信 息 保 存 到 本 地 缓 
存 ， 功 能 模块 在 某 些 情况 下 不 直接 访问 API Server， 而 是 通过 访问 缓存 
数据 来 间接 访问 API Server ° 


3.2 Controller Manager) EIAN 


Controller Manager 作 为 集群 内 部 的 管理 控制 中 心 ， 负 责 集群 内 的 
Node、Pod 副 本 、 服 务 端 点 (Endpoint) 、 命 名 空间 (Namespace) ^ 
服务 账号 (ServiceAccount) 、 资 源 定 额 (ResourceQuota) 等 的 管 
理 ， 当 某 个 Node 意 外 宕 机 时 ，Controller Manager 会 及 时 发 现 此 故障 并 
执行 目 动 化 修复 流程 ， 确 保 集 群 始终 处 于 预期 的 工作 状态 。 


如 图 3.3 所 示 ，Controller Manager 内 部 包含 Replication Controller ^ 
Node Controller ` ResourceQuota Controller ^ Namespace Controller ^ 
ServiceAccount Controller ` Token Controller ^ Service Controller 及 
Endpoint Controller 等 多 个 Controller， 每 种 Controller 都 负责 一 种 具体 的 
控制 流程 ， 而 Controller Manager 正 是 这 些 Controller 的 核心 管理 者 。 


Controller Manager 
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Controller 


Feind Node Controller 


Controller 


ServiceAccount 
Controller 


Namespace 
Controller 


Token Controller 


Service 
Controller 


Endpoint 
Controller 


图 3.3 Controller Manager 结 构 


一 般 来 说 ， 智 能 系统 和 目 动 系统 通常 会 通过 一 个 被 称 为 “操纵 系 
统 ” 的 机 构 来 不 断 修 正 系统 的 工作 状态 。 在 Kubemetes 集 群 中 ， 每 个 
Controller 都 是 这 样 一 个 “操纵 系统 ”， 它 们 通过 API Server 提 供 的 接口 实 
时 监控 整个 集群 里 的 每 个 资源 对 象 的 当前 状态 ， 当 发 生 各 种 故障 导致 
系统 状态 发 生变 化 时 ， 会 尝试 着 将 系统 状态 从 “ 现 有 状态 ”修正 到 “期 望 
状态 ”。 本 和 将 详细 分 析 Controller Manager 的 这 些 Controller 的 原理 。 


由 于 ServiceAccount Controller 5j Token Controller 是 与 安全 相关 的 
两 个 控制 器 ， 并 且 与 Service Account、Token 密 切 相 关 ， 所 以 我 们 将 对 
它们 的 分 析 放 到 后 面 的 深入 集群 安全 的 章节 中 讲解 。 


在 Kubernetes 集 群 中 与 Controller Manager 并 重 的 男 一 个 组 件 是 
Kubernetes Scheduler, ， 它 的 作用 是 将 待 调度 的 Pod (包括 通过 API 
Server 新 创建 的 Pod 及 RC 为 补足 副本 而 创建 的 Pod 等 ) 通过 一 些 复杂 的 
调度 流程 计算 出 最 佳 目 标 季 点， 然后 绑 定 到 该 和 点 上 。 本 章 最 后 会 介 
绍 Kubernetes Scheduler 调 度 器 的 基本 原理 。 


3.2.1 ReplicationController 


H T X 4r Controller Manager"? HJReplication Controller (副本 控制 
88) AU RX B Replication Controller ， 我 们 将 资源 对 象 Replication 
Controller 人 简写 为 RC， 而 本 和 中 的 Replication Controller 是 指 “ 副 本 控制 
a, METRE ° 


Replication Controller 的 核心 作用 是 确保 在 任何 时 候 集 群 中 一 个 RC 
所 关联 的 Pod 副 本 数量 保持 预 设 值 。 如 果 发 现 Pod 副 本 数量 超过 预期 
值 ， 则 Replication Controller 会 销毁 一 些 Pod 副 本 ; 反之 ，Replication 
Controller 会 目 动 创建 新 的 Pod 副 本 ， 直 到 符合 条 件 的 Pod 副 本 数量 达到 
预 设 值 。 需 要 注意 的 一 点 是 : 只 有 当 Pod 的 重启 案 略 是 Always 的 时 候 
(RestartPolicy=Always) ，Replication Controller 才 会 管理 该 Pod 的 操作 
(例如 创建 、 销 毁 、 重 启 等 ; 。 在 通常 情况 下 ，Pod 对 象 被 成 功 创建 
后 不 会 消失 ， 唯 一 的 例外 是 当 Pod 处 于 succeeded 或 failed 状 态 的 时 间 过 
长 (超时 参数 由 系统 设 定 ) 时 ， 该 Pod 会 被 系统 自动 回收 ， 管 理 该 Pod 
的 副本 控制 器 将 在 其 他 工作 节点 上 重新 创建 、 运 行 该 Pod 副 本 。 


RC 中 的 Pod 模 板 就 像 一 个 模具 ， 模 具 制 作出 来 的 东西 一 旦 离开 模 
具 ， 它 们 之 间 殊 再 也 没关系 了 。 同样 ， 一 旦 Pod 被 创建 完毕 ， 无 论 模 
板 如 何 变化 ， 甚 至 换 成 一 个 新 的 模板 ， 也 不 会 影响 到 已 经 创建 的 
Pod。 此 外 ，Pod 可 以 通过 修改 它 的 标签 来 实现 脱离 RC 的 管控 。 该 方法 
可 以 用 于 将 Pod 从 集群 中 迁移 、 数 据 修复 等 调试 。 对 于 被 迁移 的 Pod 副 
本 ，RC 会 目 动 创建 一 个 新 的 副本 车 换 被 迁移 的 副本 。 需 要 注意 的 是 ， 
删除 一 个 RC 不 会 影响 它 所 创建 的 Pod。 如 果 想 删除 一 个 RC 所 控制 的 


Pod， 则 需要 将 该 RC 的 副本 数 (Replicas) 属性 设置 为 0， 这 样 所 有 的 
Pod 副 本 都 会 被 目 动 删 除 。 


我 们 最 好 不 要 越过 RC 而 直接 创建 Pod， 因 为 Replication Controller 
会 通过 RC 管 理 Pod 副 本 ， 实 现 目 动 创 建 、 补 足 、 和 替换、 删除 Pod 副 本 ， 
这 样 能 提高 系统 的 容 灾 能 力 ， 减 少 由 于 蔬 点 拓 种 等 意外 状况 造成 的 损 
失 。 即 使 你 的 应 用 程序 只 用 到 一 个 Pod 副 本 ， 我 们 也 强烈 建议 使 用 RC 
来 定义 Pod 。 


我 们 总 结 一 下 Replication Controller 的 职责 ， 如 下 所 述 e 


(1) 确保 当前 集群 中 有 且 仅 有 N 个 Pod 实 例 ，N 是 RC 中 定义 的 Pod 
(2) 通过 调整 RC 的 spec.replicas 属 性 值 来 实现 系统 扩容 或 者 缩 


(3) 通过 改变 RC 中 的 Pod 模 板 (主要 是 镜像 版 本 ) 来 实现 系统 的 
滚动 升级 。 
最 后 ， 我 们 总 结 一 下 Replication Controller 的 典型 使 用 场景 ， 如 下 
所 述 。 
(1) 重新 调度 (Rescheduling) 。 如 前 面 所 提 及 的 ， 不 管 你 想 运 
行 1 个 副本 还 是 1000 个 副本 ， 副 本 控制 颖 都 能 确保 指定 数量 的 副本 存在 
于 集群 中 ， 即 使 发 生 市 点 故障 或 Pod 副 本 被 终止 运行 等 意外 状况 。 


(2) 弹性 伸缩 (Scaling) 。 手 动 或 者 通过 自动 扩容 代理 修改 副本 
控制 秦 的 spec.replicas 属 性 值 ， 非 常 容 易 实 现 扩 大 或 缩小 副本 的 数量 。 


(3) 滚动 更 新 (Rolling Updates) 。 副 本 控制 器 被 设计 成 通过 逐 
个 替换 Pod 的 方式 来 辅助 服务 的 浚 动 更 新 。 推 荐 的 方式 是 创建 一 个 新 
的 只 有 一 个 副本 的 RC， 者 新 的 RC 副 本 数量 加 1， 则 旧 的 RC 的 副本 数量 
城 1， 直 到 这 个 旧 的 RC 的 副本 数量 为 委 ， 然 后 删除 该 旧 的 RC。 通 过 上 
述 模 式 ， 即 使 在 深 动 更 新 的 过 程 中 发 生 了 不 可 预料 的 错 座 ，Pod 集 合 
的 更 新 也 都 在 可 控 范 围 内 。 在 理想 情况 下 ， 深 动 更 靳 控制 右 需 要 将 准 
备 吏 绪 的 应 用 考虑 在 内 ， 并 保证 在 集群 中 任何 时 刻 都 有 足够 数量 的 可 
用 Pod。 


3.2.2 NodeController 


kubelet 进 程 在 启动 时 通过 API Server 注 册 自 身 的 节点 信息 ， 并 定时 
回 API Server 汇 报 状态 信息 ，API Server 接 收 到 这 些 信息 后 ， eu 
居 更 新 到 etcd 中 ，etcd 中 存储 的 节点 信息 包括 广 点 健康 状况 、 节 点 资 
源 、 市 点 名 称 、 太 点 地 址 信息 、 操 作 系 统 版 本 、Docker 版 本 、kubelet 
版 本 等 。 节 点 健康 状况 包含 “就 绪 ”(True)“ 未 就 绪 ”(False) 和 “未 
知 ” (Unknown) 三 种 。 


Node Controller 通 过 API Server 实 时 获取 Node 的 相关 信息 ， 实 现 管 
理 和 监控 集群 中 的 各 个 Node 广 点 的 相关 控制 功能 ，NodeController 的 核 
心 工 作 流 程 如 图 3.4 所 示 。 


aro ntroller Manager Bet T 
cidr” 参数， 则 为 每 


we EE e Spec.PodCIDR” 


逐个 读 取 Node 信 息 ， 并 和 本 


地 nodeStatusMap 做 比较 


没有 收 到 节点 信息 或 第 一 次 收 在 指定 时 间 内 收 到 新 的 节 
到 节点 信息 ， 或 在 该 处 理 过 程 FE 指 定时 间 内 收 到 新 点 信息 ， 但 节点 状态 没 发 
a “健康 ” 人 E on 


用 Master 节 点 的 系统 时 间作 用 Master 节 点 的 系统 时 间作 用 Master 节 点 的 系统 时 间作 为 探测 时 
为 探测 时 间 和 节点 状态 变化 为 探测 时 间 和 节点 状态 变化 间 , 用 上 次 节点 信息 中 的 节点 状态 变 
时 间 时 间 化 时 间作 为 该 节点 的 状态 变化 时 间 


如 果 在 某 一 段 时 间 内 没有 收 到 节点 状 
态 信 息 ， 则 设置 节点 状态 为 “未 知 ” 


删除 节点 或 同步 
节点 信息 


3.4 Node Controller 流 程 


对 流程 中 关键 点 的 解释 如 下 。 


(1) Controller Manager 在 启动 时 如 果 设 置 了 --cluster-cidr 参 数 ， 
那么 为 每 个 没有 设置 Spec.PodCIDR 的 NodeT 点 生成 一 个 CIDR 地 址 ， 
并 用 该 CIDR 地 址 设置 节点 的 Spec.PodCIDR 属 性 ， 这 样 做 的 目的 是 防止 
不 同 节点 的 CIDR 地 址 发 生 冲 突 。 


(2) 逐个 读 取 节点 信息 ， 多 次 尝试 修改 nodeStatusMap 中 的 节点 
状态 信息 ， 将 该 玉 点 信息 和 Node Controller 的 nodeStatusMap 中 保存 的 
廊 点 信息 做 比较 。 如 果 判 断 出 没有 收 到 kubelet 发 送 的 节点 信息 、 第 1 次 
收 到 节点 kubelet 发 送 的 节点 信息 ， 或 在 该 处 理 过 程 中 节点 状态 变 成 
非 “ 健 康 ” 状 态 ， 则 在 nodeStatusMap 中 保存 该 节点 的 状态 信息 ， 并 用 
Node Controller 所 在 节点 的 系统 时 间作 为 探测 时 间 和 市 点 状态 变化 时 
间 。 如 果 判 断 出 在 指定 时 间 内 收 到 新 的 节点 信息 ， 且 节点 状态 发 生变 
化 ， 则 在 nodeStatusMap 中 保存 该 节点 的 状态 信息 ， 并 用 Node 
Controller 所 在 方 点 的 系统 时 间作 为 探测 时 间 和 市 点 状态 变化 时 间 。 如 
果 判 断 出 在 指定 时 间 内 收 到 新 的 节点 信息 ， 但 节点 状态 没 发 生变 化 ， 
则 在 nodeStatusMap 中 保存 该 节点 的 状态 信息 ， 并 用 Node Controller 所 
在 节点 的 系统 时 间作 为 探测 时 间 ， 用 上 次 节点 信息 中 的 节点 状态 变化 
时 间作 为 该 节点 的 状态 变化 时 间 。 如 果 判 断 出 在 某 一 段 时 间 
(gracePeriod) 内 没有 收 到 节点 状态 信息 ， 则 设置 节点 状态 为 “未 
Al" (Unknown) ， 并 且 通 过 API Server 保 存 节 点 状态 。 


(3) ASSERT AA, WRT RRA ASE a KA, MEE 
TRAM ROA, AUT NORD SI BR © WERT RASA 
非 * 就 绪 ” 状 态 ， 且 系统 指定 了 Cloud Provider, ， 则 Node Controller] FA 
Cloud Provider 查 看 方 点 ， 若 发 现 节 点 故障 ， 则 删除 etcd 中 的 节点 信 
晨 ， 并 删除 和 该 节点 相关 的 Pod 等 资源 的 信息。 


3.2.3 ResourceQuotaController 


作为 完备 的 企业 级 的 容器 集群 管理 平台 ，Kubernetes 也 提供 了 资 
源 配 额 管理 (ResourceQuota Controller) 这 一 高 级 功能 ， 资 源 配 额 管理 
确保 了 指定 的 资源 对 象 在 任何 时 候 都 不 会 超 量 占用 系统 物理 资源 ， 避 
免 了 由 于 某 些 业务 进程 的 设计 或 实现 的 缺陷 导致 整个 系统 运行 紊乱 其 
至 意外 宕 机 ， 对 整个 集群 的 平稳 运行 和 稳定 性 有 非常 重要 的 作用 。 


日 前 Kubernetes 支 持 如 下 三 个 层次 的 资源 配额 管理 。 


(1) 容器 级 别 ， 可 以 对 CPU 和 Memory 进 行 限制 。 


(2) Pod 级 别 ， 可 以 对 一 个 Pod 内 所 有 容器 的 可 用 资源 进行 限 
制 。 


(3) Namespace 级 别 ， 为 Namespace (多 租户 ) 级 别 的 资源 限 
制 ， 包 括 : 


Pod ; 
ReplicationControllerZi Œ ; 
ServiceZ Œ ; 
ResourceQuota Zi Œ ; 
Secretzi & ; 


可 持 有 的 PV (Persistent Volume) 数量 。 


Kubernetes 的 配额 管理 是 通过 Admission Control 〈 准 入 控制 ) KFE 
制 的 ，Admission Control 当 前 提供 了 两 种 方式 的 配额 约束 ， 分 别 是 
LimitRanger 与 ResourceQuota。 其 中 LimitRanger 作 用 于 Pod 和 Container 
上 ， 而 ResourceQuota 则 作用 于 Namespace 上 ， 限 定 一 个 Namespace 里 的 
各 类 资源 的 使 用 总 额 。 


如 图 3.5 所 示 ， 如 果 在 Pod 定 义 中 同时 声明 了 LimitRanger， 则 用 户 
通过 API Server 请 求 创建 或 修改 资源 时 ，Admission Control 会 计算 当前 
配额 的 使 用 情况 ， 如 果 不 符合 配额 约束 ， 则 创建 对 象 失 败 。 对 于 定义 
了 ResourceQuota 的 Namespace, ResourceQuota Controller 组 件 则 负责 定 
期 统计 和 生成 该 Namespace 下 的 各 类 对 象 的 资源 使 用 总 量 ， 统 计 结 
包括 Pod、Service、RC 、Secret 和 Persistent Volume 等 对 象 实例 个 数 ， 
以 及 该 Namespace 下 所 有 Container 实 例 所 使 用 的 资源 量 (目前 包括 CPU 
MAF) ， 然 后 将 这 些 统计 结果 写 入 etcd 的 resourceQuotaStatusStorage 
目录 (resourceQuotas/status) 中 。 写 入 resourceQuotaStatusStorage 的 内 
容 包 仿 Resource 名 称 、 配 额 值 (ResourceQuota 对 象 中 spec.hard 域 下 包 
含 的 资源 的 值 ) 、 当 前 使 用 值 (ResourceQuota Controller 统 计 出 来 的 
值 ) 。 随 后 这 些 统计 信息 被 Admission Control 使 用 ， 以 确保 相关 
Namespace 下 的 资源 配额 总 量 不 会 超过 ResourceQuota 中 的 限定 值 。 


Resource Quota, Pad. 


Service, RC, Secret#l 


Persistent Volume 


请 求 创建 资源 


创建 、 修 改 、 删 除 资源 
信息 ， 并 同步 到 etcd 


Admission Controller 


ResourceQuota Controller 


iA Resource 
Quota 


3& [B] Resource 
Quota 


读 取 各 类 资源 信息 ， 
同时 统计 这 些 资源 ， 
并 将 结果 写 入 etcd 


返回 Resource 
Quota 


TIT 


判断 请 求 是 否 合法 ， 
并 返回 结果 


3.5 ResourceQuota Controller 流 程 


3.2.4 NamespaceController 


用 户 通 过 API Server FY DA fill & Xr HY Namespace 7f f f£ 1E etcd FP , 
Namespace ControllerzE AY 38 i API Serveriž HUX% Namespacefzs E, ° WH 
R Namespace 被 API 标 识 为 优雅 删除 (通过 设置 删除 期 限 ， 即 
DeletionTimestamp 属性 被 设置 ) ， 则 将 该 NameSpace 的 状态 设置 
成 “Terminating” 并 保存 到 etcd 中 。 同 时 Namespace Controller 删 除 该 
Namespace F HJServiceAccount ` RC ` Pod ` Secret ^ PersistentVolume ^ 
ListRange、ResourceQuota 和 Event 等 资源 对 象 。 


当 Namespace 的 状态 被 设置 成 *Terminating” 后 HH Admission 
Controller 的 NamespaceLifecycle 插 件 来 阻止 为 该 Namespace 创 建新 的 资 
源 。 同 时 ， 在 Namespace Controller 删 除 完 该 Namespace 中 的 所 有 资源 
对 象 后 ，Namespace Controller 对 该 Namespace 执 行 finalize 操 作 ， 删 除 
Namespace 的 spec.finalizers 域 中 的 信息 。 


如 果 Namespace Controller 观 察 到 Namespace 设 置 了 删除 期 限 ， 同 
时 Namespace 的 spec.finalizers 域 值 是 空 的 ， 那 么 Namespace Controller 将 
通过 API Server 删 除 该 Namespace 资 源 。 


3.2.5 Service Controller = Endpoint Controller 


d fi] 25 Ui Ut Endpoints Controller ， 在 这 之 前 ， 让 我 们 先 看 看 
Service、Endpoints 写 Pod 的 关系 ， 如 图 3.6 所 示 ，Endpoints 表 示 了 一 个 
Service 对 应 的 所 有 Pod 副 本 的 访问 地 址 ， 而 Endpoints Controllers ze fA 
责 生 成 和 维护 所 有 Endpoints 对 和 象 的 控制 器 。 


spec.selector:app=MyApp 


Endpoints(MyService ) 


ports: 


-— = 
Nu di 
PODIP: PORT — "^--.. 
^ ~ 


at C ~ 
Backend Pod Backend Pod Backend Pod Backend Pod 
labels:app=MyApp labels:app=MyApp labels:app=MyApp labels:app=MyApp 


图 3.6 Service ` Endpoint ^ PodAyKA 


. 
- 
-- 
- 
- 
- 
zie 
-- 
- 


它 负责 监 听 Service 和 对 应 的 Pod 副 本 的 变化 ， 如 果 监 测 到 Service 
被 删除 ， 则 删除 和 该 Service 同 名 的 Endpoints 对 象 ; 如 果 监 测 到 新 的 
Service 被 创建 或 者 修改 ， 则 根据 该 Service 信 息 获 得 相关 的 Pod 列 表 ， 
然后 创建 或 者 更 新 Service 对 应 的 Endpoints 对 象 。 如 果 监 测 到 Pod 的 事 
件 ， 则 更 新 它 所 对 应 的 Service 的 Endpoints 对 象 ( 增 加、 删除 或 者 修改 
对 应 的 Endpoint 条 目 ) 。 


那么 ，Endpoints 对 象 是 在 哪里 被 使 用 的 呢 ? 答案 是 每 个 Node 上 的 
kube-proxy 进 程 ，kube-proxy 进 程 获取 每 个 Service 的 Endpoints， 实 现 了 
Service 的 负载 均衡 功能 。 在 后 面 的 章节 中 我 们 会 深入 讲解 这 部 分 内 


vw o 


m 


接 下 来 我 们 说 说 Service Controller 的 作用 ， 它 其 实 是 属于 
Kubemetes 集 群 与 外 部 的 云 平台 之 则 的 一 个 接口 控制 器 9 Service 
Controller 监 听 Service 的 变化 ， 如 采 是 一 个 LoadBalancer 类 型 的 Service 

(externalLoadBalancers=true) ， 则 Service Controller 人 确保 外 部 的 云 平 
台 上 该 Service 对 应 的 LoadBalancer 实 例 被 相应 地 创建 、 删 除 及 更 新 路 
由 转发 表 〈 根 据 Endpoints 的 条 目 ) ° 


3.83 Scheduler 原 理 分 析 


我 们 在 前 面 深入 分 析 了 Controller Manager 及 它 所 包含 的 各 个 组 件 
的 运行 机 制 。 本 节 我 们 将 继续 对 Kubernetes 中 负责 Pod 调 度 的 重要 功能 
模块 Kubernetes Scheduler 的 工作 原理 和 运行 机 制 做 深入 分 析 。 


Kubernetes Scheduler 在 整个 系统 中 承担 了 “承上启下 ”的 重要 功 
能 ,“ 承 上 ”是 指 它 负责 接收 Controller Manager 创 建 的 新 Pod， 为 其 安排 
一 个 落脚 的 “家 ”一 一 目标 Node;“ 启 下 * 是 指 安置 工作 完成 后 ， 目 标 
Node 上 的 kubelet 服 务 进程 接管 后 继 工 作 ， 人 负责 Pod 和 生命 周期 中 的 “下 半 


具体 来 说 ，Kubernetes Scheduler 的 作用 是 将 待 调度 的 Pod (API 狐 
创建 的 Pod、Controller Manager 为 补足 副本 而 创建 的 Pod 等 ) 按照 特定 
的 调度 算法 和 调度 策略 绑 定 (Binding) 到 集群 中 的 某 个 合适 的 Node 
上 ， 并 将 绑 定 信息 写 入 etcd 中 。 在 整个 调度 过 程 中 涉及 三 个 对 象 ， 分 
别 是 : 待 调度 Pod 列 表 、 可 用 Node 列 表 ， 以 及 调度 算法 和 策略 。 人 简单 
地 说 ， 殉 是 通过 调度 算法 调度 为 待 调度 Pod 列 表 的 每 个 pod 从 Node 列 表 
中 选择 一 个 最 适合 的 Node 。 


了 随后， 目标 节 点 上 的 kubelet 通 过 API Server 监 听 到 Kubernetes 
Scheduler 产 生 的 Pod 绑 定 事 件 ， 然 后 获取 对 应 的 Pod 清 单 ， 下 载 Image 
镜像 ， 并 启动 容器。 完整 的 流程 如 图 3.7 所 示 。 


Master 


Scheduler 


PodQueue: 


NodeList: 


É3.7 Scheduler f£ 


Kubernetes Scheduler 当 前 提供 的 默认 调度 流程 分 为 以 下 两 步 。 


(1) 预选 调度 过 程 ， 即 遍历 所 有 目标 Node， 俑 选 出 符合 要 求 的 
候选 节点 。 为 此 ，Kubernetes 内 置 了 多 种 预选 策 四 Predicates) 供 
用 户 选 择 。 


(2) 确定 最 优 和 节点， 在 第 1 步 的 基础 上 ， 采 用 优选 策略 (xxx 
Priority) 计算 出 每 个 候选 节点 的 积分 ， 积 分 最 高 者 胜出 。 


Kubernetes Scheduler 的 调度 流程 是 通过 插件 方式 加 载 的 “调度 算法 
提供 者 ”(AlgorithmProvider) 具体 实现 的 。 一 个 AlgorithmProvider 其 
实 束 是 包括 了 一 组 预选 策略 与 一 组 优先 选择 案 上 略 的 结构 体 ， 注 册 
AlgorithmProvider 的 函数 如 下 : 


func  RegisterAlgorithmProvider(name string, 


predicateKeys, priorityKeys util.StringSet) 


它 包 含 三 个 参数 : “name string” 参 数 为 AAT; *predicateKeys" = 
数 为 算法 用 到 的 预选 策略 集合 “priorityKeys” 为 算法 用 到 的 优选 策略 


集合 。 


Scheduler 中 可 用 的 预选 策略 包含 : NoDiskConflict ^ 
PodFitsResources PodSelectorMatches È PodFitsHost ` 
CheckNodeLabelPresence ` CheckServiceA ffinity#/ PodFitsPorts RK 55 » 
其 默认 的 AlgorithmProvider 加 载 的 预选 策略 Predicates 包括: 
PodFitsPorts PodFitsPorts ) PodFitsResources 

( PodFitsResources ) ^ NoDiskConflict ( NoDiskConflict ) > 
MatchNodeSelector (  PodSelectorMatches  ) 和 HostName 

(PodFitsHost) ， 即 每 个 节点 只 有 通过 前 面 提 及 的 5 个 默认 预选 策略 
后 ， 才 能 初步 被 选中 ， 进 入 下 一 个 流程 。 


下 面 列 出 的 是 对 所 有 预选 策略 的 详细 说 明 。 
1) NoDiskConflict 


I jt && 5 Pod HY) GCEPersistentDisk 2 AWSElasticBlockStore 41] #4 1 
的 节点 中 已 存在 的 Pod 是 否 存 在 冲突 。 检 测 过 程 如 下 。 


(1) 首先 ， 读 取 备 选 Pod 的 所 有 Volume 的 信息 ( 即 
pod.Spec.Volumes) ， 对 每 个 Volume 执 行 以 下 步 又 进行 冲突 检测 。 


(2) 如 果 该 Volume 是 GCEPersistentDisk， 则 将 Volume 和 备 选 节点 
上 的 所 有 Pod 的 每 个 Volume 进 行 比 较 ， 如 果 发 现 相 同 的 
GCEPersistentDisk， 则 返回 false， 表 明 存 在 磁盘 冲突 ， 检 查 结束 ， 反 
馈 给 调度 器 该 备 选 节 点 不 适合 作为 备 选 Pod = 40 R iA Volume Æ 
AWsSElasticBlockStore, ， 则 将 Volume 和 备 选 节点 上 的 所 有 Pod 的 每 个 


Volume 进 行 比较 ， 如 果 发 现 相 同 的 AWSElasticBlockStore ， 则 返回 
false， 表 明 存 在 磁盘 冲突 ， 检 查 结 束 ， 反 馈 给 调度 器 该 备 选 记 点 不 适 
合 备 选 Pod 。 


(3) 如 果 检 查 完 备 选 Pod 的 所 有 Volume 均 未 发 现 冲突 ， 则 返回 
true， 表 了 明 不 存在 磁盘 冲突 ， 反 馈 给 调度 右 该 备 选 和 节点 适合 备 选 Pod。 


2) PodFitsResources 


判断 备 远 市 点 的 资源 是 否 满足 备 选 Pod 的 需求 ， 检 测 过 程 如 下 。 


(1) 计算 备 选 Pod 和 节点 中 已 存在 Pod 的 所 有 容器 的 需求 资源 
(内 存 和 CPU) 的 总 和 。 


(2) 获得 备 选 节 点 的 状态 信息 ， 其 中 包含 节点 的 资源 信息 。 


(3) 如 果 备 选 Pod 和 节点 中 已 存在 Pod 的 所 有 容器 的 需求 资源 
(内 存 和 CPU) 的 总 和 ， 超 出 了 备 选 节点 拥有 的 资源 ， 则 返回 false， 
表明 备 选 节点 不 适合 备 选 Pod， 否 则 返回 tue， 表 明 备 选 节 点 适合 备 选 
Pod ° 


3) PodSelectorMatches 
判断 备 选 节点 是 否 包 含 备 选 Pod 的 标签 选择 器 指定 的 标签 。 


(1) 如 果 Pod 没 有 指定 spec.nodeSelector 标 签 选 择 器 ， 则 返回 


true ° 


(2) 否则 ， bad iN 判断 节点 是 否 包含 备 选 
Pod 的 标签 选择 器 (spec.nodeSelector) 所 指定 的 标签 ， 如 果 包 含 ， 则 


Eltrue, AM [ulfalse » 
4) PodFitsHost 


判断 备 选 Pod 的 spec.nodeName 域 所 指定 的 节点 名 称 和 备 选 节点 的 
名 称 是 否 一致 ， 如 果 一 致 ， 则 返回 true， 否 则 返回 false。 


5) CheckNodeLabelPresence 


如 采用 户 在 配置 文件 中 指定 了 该 策略 ， 则 Scheduler 会 通过 
RegisterCustomFitPredicate 方 法 注册 该 策略 。 该 策略 用 于 判断 策略 列 出 
的 标签 在 备 选 节点 中 存在 时 ， 是 否 选择 该 备 选 节点 。 


(1) 读 取 备 选 节 点 的 标签 列表 信息 。 


(2) 如 果 策 略 配置 的 标签 列表 存在 于 备 选 节点 的 标签 列表 中 ， 且 
策略 配置 的 presence 值 为 false， 则 返回 false， 否 则 返回 true; AIR NE 
配置 的 标签 列表 不 存在 于 备 选 节点 的 标签 列表 中 ， 且 策略 配置 的 
presence 值 为 true， 则 返回 false， 人 否则 返回 true 。 


6) CheckServiceA ffinity 


WRAP EB BC BE ST KR, Mil Scheduler 3 38 wf 
RegisterCustomFitPredicate 方 法 注册 该 策略 。 该 策略 用 于 判断 备 选 点 
是 否 包含 策略 指定 的 标签 ,或 包含 和 备 选 Pod 在 相同 Service 和 
Namespace 下 的 Pod 所 在 和 点 的 标签 列表 。 如 果 存 在 ， 则 返回 true， 藻 
则 返回 false。 


7) PodFitsPorts 


判断 备 选 Pod 所 用 的 端口 列表 中 的 端口 是 否 在 备 选 节点 中 已 被 占 
用 ， 如 果 被 占用 ， 则 返回 false， 否 则 返回 true。 


Scheduler 中 的 优选 策略 包 : LeastRequestedPriority 、 

CalculateNodeLabelPriority fil BalancedResourceAllocationS » fH A, 

通过 优先 选择 策略 时 都 会 算出 一 个 得 分 ， 计 算 各 项 得 分 ， 最 终 选 出 得 
分 值 最 大 的 节点 作为 优选 的 结果 (也 是 调度 算法 的 结果 ) 。 


下 面 是 对 所 有 优选 策略 的 详细 说 明 。 
1) LeastRequestedPriority 
该 优选 策略 用 于 从 备 选 世上 点 列表 中 选 出 资源 消耗 最 小 的 和 点 。 


(1) 计算 出 所 有 备 选 节点 上 运行 的 pod 和 备 选 Pod 的 CPU 占用 量 
totalMilliCPU ° 


(2) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 内 存 占用 量 


totalMemory ° 


(3) 计算 每 个 节点 的 得 分 ， 计 算 规 则 大 致 如 下 。 


NodeCpuCapacity 为 下 点 CPU 计算 能 力 ; NodeMemoryCapacity2J 17 
点 内 存 大 小 。 


score-int(((nodeCpuCapacity-totalMilliCPU)*10)/ 
nodeCpuCapacity-*( (nodeMemoryCapacity-totalMemory)*10)/ 


nodeCpuMemory)/2) 


2) CalculateNodeLabelPriority 


如 宁 用 户 在 配置 文件 中 指定 了 该 策略 MW scheduler Z 38 3x 
RegisterCustomPriorityFunction 方 法 注册 该 策略 。 该 策略 用 于 判断 策略 
列 出 的 标签 在 备 选 和 节点 中 存在 时 ， 有 是否 选择 该 备 选 节点 。 如 有 末 备 选 季 
点 的 标签 在 优选 策略 的 标签 列表 中 且 优 选 策 上 略 的 presence 值 为 tue， 或 
者 备 选 闻 点 的 标签 不 在 优选 策略 的 标签 列表 中 且 优 选 策略 的 presence 值 
为 false， 则 备 选 节点 score=10， 否 则 备 选 节 点 score=0。 


3) BalancedResourceAllocation 


该 优先 策略 用 于 从 备 选 入 点 列表 中 选 出 各 项 资源 使 用 率 最 均衡 的 
Ta? 


(1) 计算 出 所 有 备 选 节点 上 运行 的 Pod 和 备 选 Pod 的 CPU 占 用 量 
totalMilliCPU 。 


(2) 计算 出 所 有 备 选 节点 上 运行 的 pod 和 备 选 Pod 的 内 存 占用 量 


totalMemory ° 
(3) 计算 每 个 节点 的 得 分 ， 计 算 规 则 大 致 如 下 。 


NodeCpuCapacity 为 下 点 CPU 计算 能 力 ; ~NodeMemoryCapacity T7 
点 内 存 大 小 。 


score- int(10-math.Abs(totalMilliCPU/nodeCpuCapacity- 


totalMemory/ nodeMemoryCapacity)*10) 


3.4 kubelet 运 行 机 制 分 析 


在 Kubernetes 集 群 中 ， 在 每 个 Node 节 点 〈 又 称 Minion) 上 都 会 启 
动 一 个 kubelet 服 务 进程 。 该 进程 用 于 处 理 Master 廊 点 下 发 到 本 节点 的 
任务 ， 管 理 Pod 及 Pod 中 的 容器 。 每 个 kubelet 进 程 会 在 API Server 上 注册 
六 点 上 自身 信息 ， 定 期 间 Master 广 点 汇报 节点 资源 的 使 用 情况 ， 并 通过 


pr? Hu AG 
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3.4.1 节点 管理 


节点 通过 设置 kubelet 的 启动 参数 “--register-node”， 来 决定 是 否 癌 
API Server 注 册 自 己 。 如 果 该 参数 的 值 为 tue， 那 么 kubelet 将 试 着 通过 
API Server 注 册 自 己 。 在 自 注册 时 ，kubelet 启 动 时 还 包含 下 列 参 数 。 


e --api-servers: 告诉 kubelet API Server 的 位 置 。 

e --kubeconfig: 告诉 kubelet 在 哪儿 可 以 找到 用 于 访问 API Server 的 
WEB ° 

e --cloud-provider: 告诉 kubelet 如 何 从 云 服务 商 (Iaas) 那里 读 取 到 
和 目 己 相关 的 元 数据 。 


当前 每 个 kubelet 被 授予 创建 和 修改 任何 世上 点 的 权限 。 但 是 在 实践 
中 ， 它 仅仅 创建 和 修改 目 己 。 将 来 ， 我 们 计划 限制 kubelet 的 权限 ， 仪 
允许 它 修 改 和 创建 其 所 在 市 点 的 权限 。 如 采 在 集群 运行 过 程 中 过 到 集 
群 贷 源 不 足 的 情况 ， 则 用 户 很 容易 通过 添加 机 器 及 运用 kubelet 的 目 注 
册 模 式 来 实现 扩容 。 


在 某 些 情况 下 ，Kubernetes 集 群 中 的 某 些 kubelet 没 有 选择 上 自 注 册 模 
式 ， 用 户 需 要 自己 去 配置 Node 的 资源 信息 ， 同 时 告知 Node 上 的 kubelet 
API Server 的 位 置 。 和 集群 管理 者 能 够 创建 和 修改 市 点 信息 。 如 果 管 理 者 
和 希望 手动 创建 节点 信息 ， 则 通过 设置 kubelet 的 启动 参数 “--register- 
node=false” 即 可 e 


kubelet 在 = 动 时 通过 API Server y+ Ht T HA Te A ; 并 
Server 发 送 节 点 的 新 消息 ，API Server 在 接收 到 这 些 信 息 后 ， 将 这 些 信 


已 写 入 etcd。 通 过 kubelet 的 启动 参数 “--node-status-update-frequency” 设 
置 kubelet 每 隔 多 少时 间 向 API Server 报 告 节点 状态 ， 默 认为 10 秒 。 


3.4.2 Pod f 


kubelet 通 过 以 下 几 种 方式 获取 目 身 Node 上 所 要 运行 的 Pod 清 单 。 


(1) Xf: kubelet 局 动 参数 “--config” 指 定 的 配置 文件 目录 下 的 
文件 CERA H 3& JJ “/etc/kubernetes/manifests/” ) 。 通 过 --file-check- 
frequency 设 置 检查 该 文件 目录 的 时 间 间 隔 ， 默 认为 20 秒 。 


(2) HTTP 端 点 (URL) : 通过 “--manifest-url” 人 参数 设置 。 通 过 -- 
http-check-frequency 设 置 检查 该 HTTP 端 点 数据 的 时 间 间 隔 ， 默 认为 20 
秒 。 


(3) API Server: kubelet 通 过 API Server Uretcd H 53€, [8] 27 Pod 
列表 。 


所 有 以 非 API Server 方 式 创建 的 Pod 都 叫 作 Static Pod。kubelet 将 
Static Pod 的 状态 汇报 给 API Server, API Server 为 该 Static Pod 创 建 一 个 
Mirror Pod 和 其 相 匹配 。Mirror Pod 的 状态 将 真实 反映 Static Pod 的 状 
A ° “Static Pod 被 删除 时 ， 与 之 相对 应 的 Mirror Pod 也 会 被 删除 。 在 
本 章 中 我 们 只 讨论 通过 APIServer 获 得 Pod 清 单 的 方式 。kubelet 通 过 API 
Server Client 使 用 Watch 加 List 的 方式 监听 “registrynodes/$ 当 前 万 点 的 
名 称 ” 和 “/registry/pods” 目 录 ， 将 获取 的 信息 同步 到 本 地 缓存 中 。 


kubelet 监 听 etcd， 所 有 针对 Pod 的 操作 将 会 被 kubelet 监 听 到 。 如 果 
发 现 有 新 的 绑 定 到 本 下 点 的 Pod， 则 按照 Pod 清 单 的 要 求 创建 该 Pod © 


如 果 发 现 本 地 的 Pod 被 修改 ， 则 kubelet 会 做 出 相应 的 修改 ， 比 如 删 
除 Pod 中 的 某 个 容器 时 ， 则 通过 Docker Client hR IZAKS 


如 果 发 现 删 除 本 节点 的 Pod， 则 删除 相应 的 Pod， 并 通过 Docker 
Client 删 除 Pod 中 的 容器 


kubelet 读 取 监 听 到 的 信息 ， 如 采 是 创建 和 修改 Pod 任 务 ， 则 做 如 下 
处 理 。 


(1) 为 该 Pod 创 建 一 个 数据 目录 。 

(2) MAPI Server 读 取 该 Pod 清 单 。 

(3) 为 该 Pod 挂 载 外 部 卷 (External Volume) 
(4) 下 载 Pod 用 到 的 Secret 。 


(5) 检查 已 经 运行 在 节点 中 的 Pod， 如 果 该 Pod 没 有 容器 或 Pause 
at (“kubernetes/pause” 镜 像 创 建 的 容器 ) 没有 启动 ， 则 先 停止 Pod 里 
所 有 容器 的 进程 。 如 果 在 Pod 中 有 需要 删除 的 容器 ， 则 删除 这 些 容 


Dm 
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(6) 用 “kubernetes/pause” 镜 像 为 每 个 Pod 创 建 一 个 容器 。 该 Pause 
容器 用 于 接管 Pod 中 所 有 其 他 容 右 的 网 络 。 每 创建 一 个 新 的 Pod， 
kubelet 都 会 和 完 创 建 一 个 Pause 7X s8 , Ada Gl GH fh £u 
as ° "kubernetes/pause" tm 4 A HEA 200KB, fe — “SSE 4$ / AY A ae BR 
像 。 


47) 为 Pod 中 的 每 个 容器 做 如 下 处 理 。 


ai Sa tt TL— rhashí&, Aa AAW 4 F EAW NI Docker Zt 
锋 有 的 hash 值 。 若 查找 到 容器 ， 且 两 者 的 hash 值 不 同 ， 则 休止 

Docker 中 容 需 的 进程 ， 并 停止 5 Z REKA Pause thE; AN 

者 相同 ， 则 不 做 任何 处 理 。 

。 如 果 容 器 被 终止 了 ， 且 容器 没有 指定 的 restartPolicy (Æ JA R 

E) ， 则 不 做 任何 处 理 。 

。 调用 Docker Client 下 载 容器 镜像 ， 调 用 Docker Clien& £1 Aas 


3.4.3 Aas Ree 


Pod 通 过 两 类 探 针 来 检查 容 絮 的 健康 状态 。 一 个 是 LivenessProbe 探 
针 ， 用 于 判断 容器 是 否 健康 ， 告 诉 kubelet 一 个 容 妖 什么 时 候 处 于 不 健 
康 的 状态 。 如 果 LivenessProbe 探 针 探 测 到 容 峰 不 健康 ， 则 kubelet 将 删 
除 该 容 右 ， 并 根据 容 絮 的 重启 集 上 略 做 相应 的 处 理 。 如 果 一 个 容 絮 不 包 
含 LivenessProbe 探 和 针 ， 那 么 kubelet 认 为 该 容器 的 LivenessProbe 探 针 返 
回 的 值 永远 是 “Success”; 男 一 类 是 ReadinessProbe 探 和 针 ， 用 于 判断 容器 
是 否 启动 完成 ， 且 准备 接收 请 求 。 如 采 ReadinessProbe 探 针 检 测 到 失 
败 ， 则 Pod 的 状态 将 被 修改 。Endpoint Controller 将 从 Service 的 Endpoint 
中 删除 包含 该 容 姻 所 在 Pod 的 IP 地 址 的 Endpoint 条 目 。 


kubelet 定 期 调用 容器 中 的 LivenessProbe 探 针 来 诊断 容器 的 健康 状 
(it, ° LivenessProbe£) & A F = FRSCHZT XX e 


(1) ExecAction: 在 容器 内 部 执行 一 个 命令 ， 如 果 该 命令 的 退出 
状态 码 为 0， 则 表明 容器 健康 。 


(2) TCPSocketAction: 通过 容器 的 人 P 地 址 和 端口 号 执行 TCP 检 
查 ， 如 果 端 口 能 被 访问 ， 则 表明 容器 健康 。 


(3) HTTPGetAction: 通过 容器 的 卫 地 址 和 端口 号 及 路 径 调 用 
HTTP Get 方 法 ， 如 果 曙 应 的 状态 码 大 于 等 于 200 且 小 于 等 于 400， 则 认 
为 容器 状态 健康 。 


my Ae 


LivenessProbe14 £T E & TE Pod % X. HY spec.containers. ( 4“ R AF } 
o RMA BIEN T PP Pod? Aas ERMA 7 sl: HTTPTS All 
容 絮 命令 执行 检查 。 下 面 所 列 的 内 容 实 现 了 通过 容器 命令 执行 检查 : 


NI 


livenessProbe: 
exec: 
command: 
- cat 
- /tmp/health 
initialDelaySeconds: 15 


timeoutSeconds: 1 


kubelet 在 容器 中 执行 “cat/tmp/health* 命 令 ， 如 果 该 命令 返回 的 值 
为 0， 则 表明 容 右 处 于 健康 状态 ， 否 则 表明 容 右 处 于 不 健康 状态 。 


下 面 所 列 的 内 容 实 现 了 容 右 的 HTTP 检 查 : 


livenessProbe: 
httpGet: 
path: /healthz 
port: 8080 
initialDelaySeconds: 15 


timeoutSeconds: 1 


kubelet 发 送 一 个 HITP 请 求 到 本 地 主机 和 端口 及 指定 的 路 径 ， 来 检 
查 容 希 的 健康 状况 。 


3.4.4 cAdvisor Et jg I Tai 


在 Kubernetes 集 群 中 如 何 监 控 资 源 的 使 用 情况 ? 


在 Kubernetes 集 群 中 ， 应 用 程序 的 执行 情况 可 以 在 不 同 的 级 别 上 
监测 到 ， 这 些 级 别 包 括 : 容器 、Pod、Service 和 整个 集群 。 作 为 
Kubernetes 集 群 的 一 部 分 ，Kubernetes 硕 望 提 供给 用 户 详 细 的 各 个 级 别 
的 资源 使 用 信息 ， 这 将 使 用 户 能 够 深入 地 了 解 应 用 的 执行 情况 ， 并 找 
到 应 用 中 可 能 的 瓶颈 。Heapster 项 目 为 Kubernetes 提 供 了 一 个 基本 的 监 
控 平 台 ， 它 是 集群 级 别 的 监控 和 事件 数据 集成 器 (Aggregator) 
Heapster 作 为 Pod 运 行 在 Kubernetes 集 群 中 ， 和 运行 在 Kubernetes 集 群 中 
的 其 他 应 用 相似 。Heapster Pod 通 过 kubelet (运行 在 节点 上 的 
Kubernetes 代 理 ) 发 现 所 有 运行 在 集群 中 的 节点 ， 并 查看 来 自 这 些 市 
点 的 资源 使 用 状况 信息 。kubelet 通 过 cAdvisor 获 取 其 所 在 节点 及 容器 
的 数据 ，Heapster 通 过 市 着 关联 标签 的 Pod 分 组 这 些 信 息 ， 这 些 数据 被 
推 到 一 个 可 配置 的 后 端 ， 用 于 存储 和 可 视 化 展示 。 当 前 文 持 的 后 端 包 
括 InfluxDB ( with Grafana for Visualization ) 和 Google Cloud 


Monitoring ° 
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项 目 中 ，cAdvisor 补 集成 到 Kubemetes 代 码 中 。cAdvisor 目 动 查找 所 有 
在 其 所 在 节点 上 的 容器 ， 自 动 采 集 CPU、 内 存 、 文 件 系 统 和 网 络 使 用 
的 统计 信息 。cAdvisor 通 过 它 所 在 方 点 机 的 Root 容 器 ， 采 集 并 分 析 该 
广 点 机 的 全 面 使 用 情况 。 


在 大 部 分 Kubernetes 集 群 中 ，cAdvisor 通 过 它 所 在 节点 机 的 4194 端 
口 暴露 一 个 简单 的 UI。 图 3.8 是 cAdvisor 的 一 个 截图 。 


图 3.8 ”cAdvisor 的 一 个 UI 


kubelet 作 为 连接 Kubernetes Master 和 各 池 点 机 之 则 的 桥梁 ， 管 理 运 
行 在 节点 机 上 的 Pod 和 容器 。kubelet 将 每 个 Pod 转 换 成 它 的 成 员 容 器 ， 
同时 从 cAdvisor 获 取 单 独 的 容器 使 用 统计 信息 ， 然 后 通过 该 REST API 
又 露 这 些 聚 合 后 的 Pod 资 源 使 用 的 统计 信息 。 


3.5 “kube-proxy 运 行 机 制 分 析 


我 们 在 前 面 已 经 了 解 到 ， 为 了 支持 集群 的 水 平 扩 展 、 高 可 用 性 ， 
Kubemetes 抽 象 出 了 Service 的 概念 。Service 是 对 一 组 Pod 的 抽象 ， 它 会 
根据 访问 策略 (如 负载 均衡 策略 ) 来 访问 这 组 Pod。 


Kubernetes 在 创建 服务 时 会 为 服务 分 配 一 个 虚拟 的 卫 地 址 ， 客 户 端 
通过 访问 这 个 虚拟 的 卫 地 址 来 访问 服务 ， 而 服务 则 负责 将 请 求 转发 到 
后 端的 Pod 上 。 这 不 束 是 一 个 反问 代理 吗 ? 不 错 ， 这 就 是 一 个 反问 代 
理 。 但 是 ， 它 和 普通 的 反 回 代理 有 一 些 不 同 : 首先 它 的 IP 地 址 是 虚拟 
的 ， 想 从 外 面 访问 还 需要 一 些 技巧 ;其 次 是 它 的 部 署 和 局 停 是 
Kubernetes 统 一 目 动 管理 的 。 


Service 在 很 多 情况 下 只 是 一 个 概念 ， 而 真正 将 Service 的 作用 落实 
的 是 背后 的 kube-proxy 服 务 进程 。 只 有 理解 了 kube-proxy 的 原理 和 机 
制 ， 我 们 才能 真正 理解 Service 背 后 的 实现 逻辑 。 


在 Kubernetes 集 群 的 每 个 Node 上 都 会 运行 一 个 kube-proxy 服 务 进 
程 ， 这 个 进程 可 以 看 作 Service 的 透明 代理 兼 负载 均衡 器 ， 其 核心 功能 
是 将 到 某 个 Service 的 访问 请 求 转 发 到 后 端的 多 个 Pod 实 例 上 。 对 每 一 
个 TCP 类 型 的 Kubernetes Service，kube-proxy 都 会 在 本 地 Node 上 建立 一 
个 SocketServer 来 负责 接收 请 求 ， 然 后 均匀 发 送 到 后 端 某 个 Pod 的 端口 
上 ， 这 个 过 程 默认 采用 Round Robin 负 载 均衡 算法 。 另 外 ，Kubernetes 
也 提供 通过 修改 Service 的 service.spec.sessionAffinity 参 数 的 值 来 实现 会 


话 保持 特性 的 定 癌 转发 ， 如 果 设 置 的 值 为 “ClientIP”*”， 则 将 来 自 同一 个 
ClientIP 的 请 求 都 转发 到 同一 个 后 端 Pod 上。 


此 外 ，Service 的 Cluster IP 与 NodePort 等 概念 是 kube-proxy 服 务 通过 
Iptables 的 NAT 转 换 实现 的 ，kube-proxy 在 运行 过 程 中 动态 创建 与 
Service 相 天 的 Iptables 规 则 ， 这 些 规则 实现 了 Cluster IP 及 NodePort 的 请 
求 流量 重 定 回 到 kube- proxy Es LORI MARA HU ER 口 的 功能 。 由 于 
Iptables 机 制 针 对 的 是 本 地 的 kube-proxy 端 口 ， 所 以 每 个 Node 上 都 要 运 
行 kube-proxy 组 件 ， 这 样 一 来 ， 在 Kubernetes 集 群 内 部 ， 我 们 可 以 在 任 
意 Node 上 发 起 对 Service 的 访问 请 求 。 


综 上 所 述 ， 由 于 kube-proxy 的 作用 ， 在 Service 的 调用 过 程 中 客户 
端 无 须 关 心 后 端 有 几 个 Pod， 中 间 过 程 的 通信 、 负 载 均 衡 及 故障 恢复 
都 是 透明 的 ， 如 图 3.9 所 示 。 


访问 Service 的 请 求 ， 不 论 是 用 Cluster IP+TargetPort 的 方式 ， 还 是 
用 节点 机 IP+NodePort 的 方式 ， 都 被 节点 机 的 Iptables 规 则 重 定 向 到 
kube-proxy 监 听 Service 服 务 代 理 端 口 。kube-proxy 接 收 到 Service 的 访问 
请 求 后 ， 会 如 何 选 择 后 端的 Pod 呢 ? 


集群 自动 分 配 服 
| 务 的 IP 
Cluster IP:Port 


L 


通过 Iptables 的 DNAT 
服务 路 由 信息 通过 i 
watch API Server 得 到 kube-proxy 前 传 到 kube-proxy 


HAR 


图 3.9 Service 的 负载 均衡 转发 规则 


首先 ， 目 前 kube-proxy 的 负载 均衡 器 只 文 持 RoundRobin 算 法 。 
RoundRobin 算 法 按照 成 员 列表 逐个 选取 成 员 ， 如 果 一 轮 循 环 完 ， 便 从 
头 开 始 下 一 轮 ， 如 此 循环 往复 。kube-proxy 的 负载 均衡 絮 在 
RoundRobin 算 法 的 基础 上 还 支持 Session 保 持 。 如 果 Service 在 定义 中 指 
定 了 Session 你 持 ， 则 kube-proxy 接 收 请 求 时 会 从 本 地 内 存 中 查找 是 否 
存在 来 和 目 该 请 求 耻 的 affinityState 对 象 ， 如 果 存 在 该 对 象 ， 且 Session 没 
有 超时 ， 则 kube-proxy 将 请 求 转 回 该 affinityState 所 指 癌 的 后 端 Pod。 如 
果 本 地 存在 没有 来 自 该 请 求 卫 的 affinityState 对 象 ， 则 按照 RoundRobin 
算法 为 该 请 求 挑 选 一 个 Endpoint， 并 创建 一 个 affinityState 对 象 ， 记 录 
请 求 的 IP 和 指 问 的 Endpoint。 后 面 的 请 求 束 会 “ 荞 连 ”到 这 个 创建 好 的 
affinityState 对 象 上 ， 这 就 实现 了 客户 端 IP 会 话 你 持 的 功能 。 


接 下 来 我 们 深入 分 析 kube-proxy 的 实现 细节 。 


kube-proxy 通 过 查询 和 监听 API Server 中 Service 与 Endpoints 的 变 
化 ， 为 每 个 Service 都 建立 了 一 个 “服务 代理 对 象 ”， 并 目 动 同步 。 服 务 


代理 对 象 是 kube-proxy 程 序 内 部 的 一 种 数据 结构 ， 它 包括 一 个 用 于 监 
听 此 服务 请 求 的 SocketServer，SocketServer 的 端口 是 随机 选择 的 一 个 
本 地 空 闪 端口 。 此 外 ，kube-proxy 内 部 也 创建 了 一 个 负载 均衡 絮 一 一 
LoadBalancer ，LoadBalancer 上 保存 了 Service 到 对 应 的 后 端 Endpoint 列 
表 的 动态 转发 路 由 表 ， 而 具体 的 路 由 选择 则 取决 于 Round Robin 负 载 均 
衡 算法 及 Service 的 Session 会 话 保持 (SessionAffinity) 这 两 个 特性 。 


针对 发 生变 化 的 Service 列 表 ，kube-proxy 会 逐个 处 理 。 下 面 是 具 
体 的 处 理 流程 。 


(1) 如 果 该 Service 没 有 设置 集群 IP (ClusterIP) ， 则 不 做 任何 处 
理 ， 否 则 ， 获 取 该 Service 的 所 有 端口 定义 列表 〈spec.ports 域 ) 。 


(2) 逐个 读 取 服务 端口 定义 列表 中 的 端口 信息 ， 根 据 端口 名 称 、 
Service 名 称 和 Namespace 判 断 本 地 是 否 已 经 存在 对 应 的 服务 代理 对 
象 ， 如 果 不 存 在 则 新 建 ; 如 果 存 在 并 且 Service 端 口 被 修改 过 ， 则 移 删 
除 Iptables 中 和 该 Service 端 口 相 关 的 规则 ， 关 闭 服 务 代理 对 象 ， 然 后 走 
源 建 流程 ， 即 为 该 Service 端 口 分 配 服务 代理 对 象 并 为 该 Service 创 建 相 
天 的 Iptables 规 则 。 


(3) 更 新 负载 均衡 器 组 件 中 对 应 Service 的 转发 地 址 列表 ， 对 于 新 
建 的 Service， 确 定 转发 时 的 会 话 保持 策略 。 


(4) 对 于 已 经 删除 的 Service 则 进行 清理 。 


而 针对 Endpoint 的 变化 ，kube-proxy 会 目 动 更 新 负载 均衡 磺 中 对 应 
Service 的 转发 地 址 列表 。 


下 面 讲解 kube-proxy 针 对 Iptables 所 做 的 一 些 细 和 操作 。 


kube-proxy 在 启动 时 和 监听 到 Service 或 Endpoint 的 变化 后 ， 会 在 本 
机 Iptables 的 NAT 表 中 添加 4 条 规则 链 。 


(1) KUBE-PORTALS-CONTAINER : 从 容器 中 通过 Service 
Cluster IP 和 端口 号 访问 Service 的 请 求 。 


(2) KUBE-PORTALS-HOST: 从 主机 中 通过 Service Cluster IP Fil 
端口 号 访问 Service 的 请 求 。 


(3) KUBE-NODEPORT-CONTAINER: 从 容器 中 通过 Service 的 
NodePort 端 口号 访问 Service 的 请 求 。 


(4) KUBE-NODEPORT-HOST: 从 主机 中 通过 Service 的 NodePort 
端口 号 访问 Service 的 请 求 。 


此 J^, kube-proxy 在 Iptables 中 为 每 个 Service 创建 由 Cluster 
IP+Service 端 口 到 kube-proxy 所 在 主机 IP+Service 代 理 服务 所 监听 的 端口 
的 转发 规则 。 转 发 规则 的 包 匹 配 规 则 部 分 (CRETIRIA) 如 下 所 示 : 


-m comment --comment $SERVICESTRING -p $PROTOCOL -m 


$PROTOCOL --dport $DESTPORT -d $DESTIP 


HH, “m comment--comment” 表 示 匹 配 规则 使 用 Iptables 的 显 式 扩 
展 的 注释 功能 ; “$SERVICESTRING” 为 注释 的 内 容 ; “-p$PROTOCOL- 
m$PROTOCOL--dport$DESTPORT-d$DESTIP^ 表 RR D iW 
为 “$SPROTOCOL” 且 目标 地 址 和 端口 为 <$DESTIP” 和 “$DESTPORT” 的 
BH , 其 中 , “$PROTOCOL” 可 以 为 TCP 或 
UDP, “$DESTIP” 和 “$DESTPORT” 为 Service 的 Cluster IP 和 TargetPort ° 


对 于 转发 规则 的 跳 转 部 分 〈-j 部 分 |) ， 如 果 请 求 来 自 本 地 容器 ， 
A Service 代 理 服 务 监听 的 是 所 有 的 接口 (例如 IPv4 的 地 址 为 
0.0.0.0) ， 则 跳 转 部 分 如 下 所 示 : 


-j REDIRECT --to-ports $proxyPort 
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$proxyPort 端 口 (Service 代 理 服 务 监听 的 端口 ) ; 否则 ， 跳 转 部 分 如 下 
所 示 : 


-j DNAT --to-destination proxyIP:proxyPort 


表示 该 规则 的 功能 是 实现 数据 包 转 发 ， 数 据 包 的 目的 地 址 变 
为 “proxyIP: proxyPort”( 即 Service 代 理 服 务 所 在 的 IP 地 址 和 端口 ， 这 
些 地 址 和 端口 都 会 被 奉 换 成 实际 的 地 址 和 端口 ) 


如 果 Service 类 型 为 NodePort， 则 kube-proxy 在 Iptables 中 除了 添加 
上 面 提 及 的 规则 ， 还 会 为 每 个 Service 创 建 由 NodePort 端 口 到 kube-proxy 
所 在 主机 IP+Service 代 理 服务 所 监听 的 端口 的 转发 规则 。 转 发 规则 的 包 
匹配 规则 部 分 (CRETIRIA) 如 下 所 示 : 


-m comment --comment $SERVICESTRING -p $PROTOCOL -m 
$PROTOCOL --dport $NODEPORT 


上 面 所 列 的 内 容 用 于 匹配 目的 端口 为 <$NODEPORT” 的 包 。 
转发 规则 的 跳 转 部 分 〈-j 部 分 ) 和 前 面 提 及 的 跳 转 规则 一 致 。 


看 看 kube-proxy 为 


最 后 ， 我 们 以 本 书 第 2 章 的 Hello World fii 
redis-master 服 务 所 生成 的 Iptables 转 发 规则 : 


$ iptables-save | grep redis-master 

-A KUBE-PORTALS-CONTAINER -d 10.254.208.57/32 -p tcp - 

m comment --comment "default/redis-master:" -m tcp --dport 
6379 -j REDIRECT --to-ports 42872 

-d 10.254.208.57/32 -m 

-m tcp 


-A KUBE-PORTALS-HOST 
"default/redis-master 


-p tcp 
--dport 


comment  --comment 
6379 -j DNAT --to-destination 192.168.1.130:42872 
会 被 转发 


可 以 看 到 ， 对 “redis-master"Service 的 6379 端 口 的 访问 将 
口上 。 而 42872 端 口 就 是 kube-proxy 为 这 个 Service 


到 物理 机 的 42872 端 
打开 的 随机 本 地 端口 。 
最 后 ， 给 出 本 节 的 一 个 总 结 性 的 示意 图 ， 如 图 3.10 所 示 。 
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图 3.10 ”kube-proxy 工 作 原 理 示 意图 


3.6 ”深入 分 析 集 群 安全 机 制 


Kubernetes 通 过 一 系列 机 制 来 实现 集群 的 安全 控制 ， 其 中 包括 API 
Server 的 认证 授权 、 准 入 控制 机 制 及 保护 敏感 信息 的 Secret 机 制 等 。 集 
群 的 安全 性 必须 考虑 如 下 几 个 目标 。 


(1) 保证 容器 与 其 所 在 的 宿主 机 的 隔离 。 
(2) 限制 容器 给 基础 设施 及 其 他 容器 市 来 消极 影响 的 能 力 。 


(3) 最 小 权限 原则 一 一 合理 限制 所 有 组 件 的 权限 ， 确 保 组 件 只 执 
行 它 被 授权 的 行为 ， 通 过 限制 单个 组 件 的 能 力 来 限制 它 所 能 到 达 的 权 
限 范 围 。 


(4) 明确 组 件 间 边界 的 划分 
(5) 划分 普通 用 户 和 管理 员 的 角色 。 
(6) 在 必要 的 时 候 允 许 将 管理 员 权 限 赋 给 普通 用 户 。 


(7) 允许 拥有 “Secret” 数 据 (Keys ` Certs `> Passwords) 的 应 用 在 
集群 中 运行 。 


下 面 分 别 从 Authentication ^ Authorization ^ Admission Control ^ 


Secret 和 Service Account 等 方面 来 说 明 集 群 的 安全 机 制 。 


3.6.1 API Server 认 证 


我 们 知道 ，Kubernetes 集 群 中 所 有 资源 的 访问 和 变更 都 是 通过 
Kubernetes API Server 的 REST API 来 实现 的 ， 所 以 集群 安全 的 关键 点 
束 在 于 如 何 识别 并 认证 客户 端 映 份 (Authentication) ， 以 及 随后 访问 
权限 的 授权 (Authorization) 这 两 个 关键 问题 ， 本 节 我 们 讲解 前 一 个 


问题 。 


我 们 知道 ，Kubernetes 集 群 提供 了 3 种 级 别 的 客户 端 身 份 认证 方 
式 。 


最 严格 的 HITPS 证 书 认 证 : 基于 CA 根 证 书签 名 的 双向 数字 证 书 认 
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HTTP Token 认 证 : 通过 一 个 Token 来 识别 合法 用 户 。 

HTTP Base 认 证 : 通过 用 户 名 + 密码 的 方式 认证 。 


首先 ， 我 们 说 说 HTTPS 证 书 认 证 的 原理 。 


这 里 需要 有 一 个 CA 证 书 ， 我 们 知道 CA 是 PKI 系 统 中 通信 双方 都 信 
任 的 实体 ， 被 称 为 可 信 第 三 方 (Trusted Third Party, TTP) 。CA 作 为 
可 信 第 三 方 的 重要 条 件 之 一 就 是 CA 的 行为 具有 非 否认 性 。 作 为 第 三 方 
而 不 是 简单 的 上 级 ， 就 必须 能 让 信任 者 有 追究 目 己 责任 的 能 力 。CA 通 
过 证 书证 实 他 人 的 公 钥 信息 ， 证 书 上 有 CA 的 签名 。 用 户 如 果 因 为 信任 
证 书 而 有 了 损失 ， 则 证 书 可 以 作为 有 效 的 证 据 用 于 追究 CA 的 法 律 贡 
任 。 正 是 因为 CA 承担 责任 的 承诺 ， 所 以 CA 也 被 称 为 可 信 第 三 方 。 在 
很 多 情况 下 ，CA 与 用 户 是 相互 独立 的 实体 ，CA 作 为 服务 提供 方 ， 有 


可 能 因为 服务 质量 问题 〈 例 如 ， 发 布 的 公 钥 数 据 有 错误 ) 而 给 用 户 带 
来 损失 。 在 证 书 中 绑 定 了 公 钥 数据 和 相应 私 钥 拥有 者 的 号 份 信息 ， 并 
市 有 CA 的 数字 签名 ; 证 书 中 也 包含 了 CA 的 名 称 ， 以 便于 依赖 方 找到 
CA 的 公 铀 ， 验 证 证 书 上 的 数字 签名 。 


CA 认证 涉及 诸多 概念 ， 比 如 根 证 书 、 目 签名 证 书 、 密 铀 、 私 钥 、 
加 密 算 法 及 HTTPS 等 ， 本 书 大 致 讲述 SSL 协 议 的 流程 ， 有 助 于 对 CA 认 
证 和 Kubernetes CA 认证 的 配置 过 程 的 理解 。 


如 图 3.11 所 示 ，SSL 双 向 认证 大 概 包含 下 面 儿 个 步骤 。 


(1) HTTPS 通 信 双 方 的 服务 器 端 向 CA 机 构 申 请 证 书 ，CA 机 构 古 
可 信 的 第 三 方 机 构 ， 它 可 以 是 一 个 公认 的 权威 的 企业 ， 也 可 以 是 企业 
目 身 。 企 业内 部 系统 一 般 都 用 企业 目 身 的 认证 系统 。CA 机 构 下 发 根 证 
书 、 服 务 端 证 书 及 私 钥 给 申请 者 。 


(2) HTTPS 通 信 双 方 的 客户 端 向 CA 机 构 申 请 证 书 ，CA 机 构 下 发 
根 证 书 、 客 户 端 证 书 及 私 钥 给 申请 者 。 


(3) 客户 端 回 服务器 端 发 起 请 求 ， 服 务 端 下 发 服务 端 证 书 给 客户 
端 。 客 户 端 接收 到 证 书后 ， 通 过 私 钥 解密 证 书 ， 并 利用 服务 器 端 证 书 
中 的 公 钥 认证 证 书信 息 比 较 证 书 里 的 消息 ， 例 如 域名 和 公 钥 与 服务 万 
刚刚 发 送 的 相关 消息 是 否 一 致 ， 如 采 一 致 ， 则 客户 端 认可 这 个 服务 大 
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(4) 客户 端 发 送 客户 端 证 书 给 服务 器 端 ， 服 务 端 接收 到 证 书后 ， 
通过 私 钥 解密 证 书 ， 获 得 客户 端 证 书 公 钥 ， 并 用 该 公 钥 认证 证 书信 
思 ， 确 认 客 户 端 是 否 合法 。 


(5) 客户 端 通过 随机 密 钥 加 密 信 息 ， 并 发 送 加 密 后 的 信息 给 服务 
端 。 服 务 怖 端 和 客户 端 协商 好 加 密 方 案 后 ， 客 户 端 会 产生 一 个 随机 的 
密 铀 ， 客 户 端 通过 协商 好 的 加 密 方 案 ， 加 密 该 随机 密 铀 ， 并 发 送 该 随 
机 密 钥 到 服务 句 端 。 服 务 句 端 接收 这 个 密 钥 后 ， 双 方 通信 的 所 有 内 容 
都 通过 该 随机 密 钥 加 密 。 
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图 3.11 CA 认证 流程 


如 上 所 述 是 双 回 认证 SSL 协 议 的 具体 通信 过 程 ， 这 种 情况 要 求 服 
务 器 和 用 户 双 方 都 有 证 书 。 单 向 认证 SSL 协 议 不 需要 客户 拥有 CA 证 
书 ， 对 于 上 面 的 步 又， 只 需 将 服务 希 端 验证 客户 证 书 的 过 程 去 卸 ， 以 
及 在 协商 对 称 密码 方案 和 对 称 通话 密 钥 时 ， 服 务 絮 发 送 给 客户 的 是 没 
有 加 过 密 的 (这 并 不 影响 SSL 过 程 的 安全 性 ) 密码 方案 。 


其 次 ， 我 们 来 看 看 HTTP Token 的 认证 原理 。 


HTTP Token 的 认证 是 用 一 个 很 长 的 特殊 编码 方式 的 并 且 难 以 被 模 
仿 的 字符 串 一 一 Token 来 表明 客户 喘 份 的 一 种 方式 。 在 通常 情况 下 ， 
Token 是 一 个 很 复 洒 的 子 符 串 ， 比 如 我 们 用 私 钥 符 名 一 个 字符 串 后 的 数 


据 惑 可 以 当 作 一 个 Token。 此 外 ， 每 个 Token 对 应 一 个 用 户 名 ， 存 储 在 
API Server 能 访问 的 一 个 文件 中 。 当 客户 端 发 起 API 调 用 请 求 时 ， 需 要 
在 HTTP Header 里 放 入 Token， 这 样 一 来 ，API Server 束 能 识别 合法 用 
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最 后 ， 我 们 说 说 HTTP Base 认 证 。 


我 们 知道 ，HTTP 协 议 是 无 状态 的 ， 浏 唤 絮 和 和 Web 服务器 之 间 可 以 
通过 Cookie 来 进行 身份 识别 。 桌 面 应 用 程序 (比如 新 浪 桌 面 客 户 端 、 
SkyDrive 客 户 端 、 命 令 行 程 序 ) 一 般 不 会 使 用 Cookie， 那 么 它们 与 Web 
服务 器 之 间 是 如 何 进 行 喘 份 识别 的 呢 ? 这 就 用 到 了 HTTP Base 认 证 ， 
这 种 认证 方式 是 把 “用 户 名 + 冒号 + 密码 ”用 BASE64 算 法 进行 编码 后 的 
字符 串 放 在 HITP Request 中 的 Header Authorization 域 里 发 送 给 服务 
端 ， 服 务 端 收 到 后 进行 解码 ， 获 取 用 户 名 及 密码 ， 然 后 进行 用 户 续 份 
的 鉴 权 过 程 。 


3.6.2 API Server 授 权 


对 合法 用 户 进行 授权 (Authorization) 并 且 随 后 在 用 户 访问 时 进 
行 鉴 权 ， 是 权限 与 安全 系统 的 重要 一 环 。 简 单 地 说 ， 授 权 束 是 授予 不 
同 的 用 户 不 同 的 访问 权限 ，API Server 目 前 支持 以 下 几 种 授权 策略 GB 
过 API Server 的 启动 参数 “--authorization_mode” 设 置 ) ° 


AlwaysDeny ° 


AlwaysAllow ° 
ABAC ° 


其 中 ，AlwaysDeny 表 示 拒 绝 所 有 的 请 求 ， 该 配置 一 般 用 于 测试 ; 
AlwaysAllow 表 示 接 收 所 有 的 请 求 ， 如 果 集 群 不 需要 授权 流程 ， 则 可 
以 采用 该 策略 ， 这 也 是 Kubernetes 的 默认 配置 ABAC (Attribute- 
Based Access Control) 为 基于 属性 的 访问 控制 ， 表 示 使 用 用 户 配 置 的 
授权 规则 去 匹配 用 户 的 请 求 。 


为 了 简化 授权 的 复杂 上 度 ， 对 于 ABAC 模 式 的 授权 策略 ，Kubernetes 
仅 有 下 面 四 个 基本 属性 。 


。 用户 名 (代表 一 个 已 经 被 认证 的 用 户 的 字符 型 用 户 名 ) 。 

。 是否 是 只 读 请 求 Le ell gts 卖 的 ) 。 
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。 被 访问 对 象 所 属 的 Namespace ° 


当 我 们 为 API Server 启 用 ABAC 模 式 时 ， 需 要 指定 授权 策略 文件 的 
路 径 和 名 字 (--authorization_policy_file=SOME_FILENAME) ， 授 权 
策略 文件 里 的 每 一 行 都 是 一 个 Map 类 型 的 JSON 对 象 ， 被 称 为 “访问 策 
略 对 象 ?， 我 们 可 以 通过 设置 “访问 策略 对 象 * 中 的 如 下 属性 来 确定 具体 
的 授权 行为 。 


。 user (用 户 名 ) : 为 字符 串 类 型 ， 该 字符 串 类 型 的 用 户 名 来 源 于 
Token 文 件 或 基本 认证 文件 中 的 用 户 名 字段 的 值 。 

e readonly (只 读 标识 ) : 为 布尔 类 型 ， 当 它 的 值 为 tue 时 ， 表 明 该 
策略 允许 GET 请 求 通过 。 

e resource (资源 ) : 为 字符 串 类 型 ， 来 自 于 URL 的 资源 ， 例 
如 “Pods”。 

e namespace (命名 空间 ) : 为 字符 串 类 型 ， 表 明 该 策略 允许 访问 某 


个 Namespace 的 资源 。 


例如 ， 我 们 要 实现 如 下 访问 控制 。 

(1) 允许 用 户 alice 做 任何 事情 

(2) kubelet 只 能 访问 Pod 的 只 读 API。 

(3) kubelet 能 读 和 写 Event 对 象 。 

(4) 用 户 bob 只 能 访问 myNamespace 中 的 Pod 的 只 读 API。 
则 满足 上 述 要 求 的 授权 策略 文件 的 内 容 写法 如 下 : 


{"user":"alice"} 


{"user":"kubelet", "resource": "pods", "readonly": 


true} 


{"user":"kubelet", "resource": "events"} 
{"user":"bob", "resource": "pods", "readonly": true, 
"ns": " myNamespace "} 


当 客 户 端 发 起 API Server 调 用 时 ，API Server 内 部 要 先进 行 用 户 认 
证 ， 接 下 来 执行 用 户 鉴 权 流 程 ， 鉴 权 流 程 通过 之 前 提 到 的 “授权 策 
略 ” 来 决定 一 个 API 调 用 是 否 合法 。 当 API Server 接 收 到 请 求 后 ， 会 读 取 
该 请 求 中 的 数据 ， 生 成 一 个 “访问 策略 对 象 ?”， 如 采 该 请 求 中 不 带 某 些 
属性 (Namespace) ， 则 这 些 属性 的 值 将 根据 属性 类 型 的 不 同 ， 设 
置 不 同 的 默认 值 〈 例 如 为 字符 串 类 型 的 属性 设置 一 个 空 字 符 串 ; 为 布 
尔 类 型 的 属性 设置 false; 为 数值 类 型 的 属性 设置 0) 。 然 后 用 这 个 “ 访 
问 策 上 略 对 象 "? 和 授权 策略 文件 中 的 所 有 “访问 策略 对 象 ? 逐 条 匹配 ， 如 果 
至 少 有 一 个 策略 对 象 被 匹配 上 ， 则 该 请 求 将 被 鉴 权 通过 ， 否 则 终止 
API 调 用 流程 ， 并 返回 客户 端 错 误 调 用 人 码 。 


3.6.3 Admission Control 准 入 控制 


突破 了 之 前 所 说 的 认证 和 鉴 权 两 道 关 口 之 后 ， 客 户 端的 调用 请 求 
束 能 够 得 到 API Server 的 真正 啊 应 了 吗 ? 答案 是 : 不 能 ! 这 个 请 求 还 需 
要 通过 Admission Control 所 控制 的 一 个 “ 准 入 控制 链 * 的 层 层 考 验 ， 官 方 
标准 的 “关卡 ”有 近 十 个 之 多 ， 而 且 能 目 定 义 扩 展 ! 笔者 名 然 在 想 ， 如 
采 在 幼儿 园 的 时 候 ， 老 师 丈 告诉 我 们 长 大 后 还 要 读 小 学 ， 参 加 中 考 、 
高 考 、 公 司 面试 、 职 称 考 试 ， 等 等 ， 我 们 还 会 天 天 去 幼儿 园 吗 ? 


Admission Control 配 备 有 一 个 “ 准 入 控制 器 ”的 列表 ， 发 送 给 API 
Server 的 任何 请 求 都 需要 通过 列表 中 每 个 准 入 控制 颖 的 检查 ， 检 查 不 
通过 ， 则 API Server 拒 绝 此 调用 请 求 。 此 外 ， 准 入 控制 器 还 能 够 修改 请 
求 参 数 以 完成 一 些 自 动 化 的 任务 ， 比 如 ServiceAccount 这 个 控制 器 。 当 
前 可 配置 的 准 入 控制 器 如 下 。 


AlwaysAdmit: 人 允许 所 有 请 求 。 

AlwaysPullImages: 在 启动 容器 之 前 总 是 去 下 载 镜 像 ， 相 当 于 在 
每 个 容器 的 配置 项 imagePullPolicy=Always ° 

AlwaysDeny: 禁止 所 有 请 求 ， 一 般 用 于 测试 。 
DenyExecOnPrivileged: 它 会 拦截 所 有 想 在 Privileged Container 上 
执行 命令 的 请 求 。 如 果 你 的 集群 支持 Privileged Container, WA 
望 限制 用 户 在 这 些 Privileged Container 上 执行 命令 ， 那 么 强烈 推荐 
你 使 用 它 。 

ServiceAccount: 这 个 plug-in 将 serviceAccounts 实 现 了 自动 化 ， 默 
认 局 用 ， 如 果 你 想 要 使 用 ServiceAccount 对 象 ， 那 么 强烈 推荐 你 使 


用 它 ， 后 面 讲述 ServiceAccount 的 章 世 会 详细 说 明 其 作用 。 

SecurityContextDeny: 这 个 插件 将 使 用 了 SecurityContext 的 Pod 中 

定义 的 选项 全 部 失效 。SecurityContext 在 Container 中 定义 了 操作 系 

统 级 别 的 安全 设 定 (uid、gid、capabilities、SELinux 等 ) 。 

ResourceQuota: 用 于 配额 管理 目的 ， 作 用 于 Namespace 上 ， 它 会 

观察 所 有 的 请 求 ， 确 保 在 namespace 上 的 配额 不 会 超标 。 推 荐 在 

Admission Control 参 数列 表 中 这 个 插件 排 最 后 一 个 。 

LimitRanger: 用 于 配额 管理 ， 作 用 于 Pod 与 Container 上 ， 确 保 Pod 

与 Container 上 的 配额 不 会 超标 。 

e NamespaceExists (已 过 时 ) : 对 所 有 请 求 校 验 namespace 是 否 已 存 
在 ， 如 果 不 存在 则 拒绝 请 求 。 已 合并 人 至 NamespaceLifecycle。 

e NamespaceAutoProvision (已 过 时 ) : 对 所 有 请 求 校 验 
namespace, ， 如 果 不 存在 则 自动 创建 该 namespace ， 推 荐 使 用 
NamespaceLifecycle ° 

e NamespaceLifecycle: 如 采 和 尝试 在 一 个 不 存在 的 namespace 中 创建 
资源 对 象 ， 则 该 创建 请 求 将 被 拒绝 。 当 删除 一 个 namespace 时 ， 系 
统 将 会 删除 该 namespace 中 的 所 有 对 象 ， 包 括 Pod、Service 等 。 


在 API Server 上 设置 --admission-control 参 数 ， 即 可 定制 我 们 需要 的 
准 入 控制 链 ， 如 果 启 用 多 种 准 入 控制 选项 ， 则 建议 的 设置 〈 含 加 载 顺 
序 ) 如 下 : 


--admission- 
control=NamespaceLifecycle,LimitRanger,SecurityContextDeny, 


ServiceAccount,ResourceQuota 


KGB 4 EA FE ll as OB RA DHE, RR PORE BTA 
SecurityContextDeny ^ ResourceQuota 及 LimitRanger 这 三 个 准 入 控制 


HE 


für o 
1) SecurityContextDeny 


SecurityContext 218 Hj T £i 88 PRE ASKS (uid ^ gid ^ 


capabilities ^ SELinux role 5$ ) 。 Admission Control 的 


SecurityContextDeny 插 件 的 作用 是 ， 禁 止 创 建设 置 了 SecurityContext 的 
Pod， 例 如 包含 下 面 这 些 配置 项 的 Pod: 


spec.containers.securityContext.seLinuxOptions 


spec.containers.securityContext.runAsUser 


2) ResourceQuota 


VEN $25 Hl ait ResourceQuota 4s X Be 8 BR ri] SES Namespace # 81] & BT 
源 的 数量 ， 而 且 能 够 限制 某 个 Namespace 中 被 Pod 所 请 求 的 资源 总 量 。 
该 准 入 控制 器 和 资源 对 象 ResourceQuota 一 起 实现 了 资源 配额 管理 。 


3) LimitRanger 


准 入 控制 器 LimitRanger 的 作用 类 似 于 上 面 的 ResourceQuota 控 制 
器 ， 针 对 Namespace 资 源 的 每 个 个 体 (Pod 与 Container 等 ) 的 资源 配 
额 。 该 插件 和 资源 对 象 LimitRange 一 起 实现 资源 限制 管理 。 


3.6.4 Service Account 


Service Account 也 是 一 种 账号 ， 但 它 并 不 是 给 Kubernetes 的 集群 的 
AP (系统 管理 员 、 运 维 人 员 、 租 户 用 户 等 ) 使 用 的 ， 而 是 给 运行 在 
Pod 里 的 进程 用 的 ， 它 为 Pod 里 的 进程 提供 必要 的 身份 证 明 。 


在 继续 学 习 之 前 ， 请 回忆 一 下 本 章 前 面 所 说 的 API Server 的 认证 一 


我 们 知道 ， 正 常情 况 下 ， 为 了 确保 Kubenetes 集 群 的 安全 ，API 
Server 都 会 对 客户 端 进行 身份 认证 ， 认 证 失败 的 客户 端 无 法 进行 API 调 
用 。 此 外 ，Pod 中 访问 Kubenetes API Server 服 务 的 时 候 ， 是 以 Service 方 
式 访问 服务 名 为 kubernetes 的 这 个 服务 的 ， 而 kubernetes 服 务 又 只 在 
HTTPS 安 全 端口 443 上 提供 服务 ， 那 么 如 何 进 行 身 份 认 证 呢 ? 这 的 确 
是 个 谜 ， 因 为 Kuberetes 的 官方 文档 并 没有 清楚 说 明 这 个 问题 。 


通过 查看 官方 源码 ， 我 们 发 现 这 是 在 用 一 种 类 似 HTTP Token 的 新 
的 认证 方式 Service Account Auth, Pod 中 的 客户 端 调用 
kubernetesAPI 的 时 候 ， 在 HTTP Header 中 传递 了 一 个 Token 字 符 串 ， 这 
类 似 于 之 前 提 到 的 HTTP Token 认 证 方式 ， 但 又 有 以 下 几 个 不 同 点 。 


。 这 个 Token 的 内 容 来 目 Pod 里 指定 路 径 下 的 一 个 文件 
(/run/secrets/kubernetes.io/serviceaccount/token) ， 这 种 Token 是 动 
态 生 成 的 ， 确 切 地 说 ， 是 由 Kubernetes Controller 进 程 用 API Server 
的 私 钥 (--service-account-private-key-file 指 定 的 私 钥 ) 签名 生成 的 
一 个 JWT Secret ° 


官方 提供 的 客户 端 REST 框 架 代码 里 ， 通 过 HTTPS 方 式 与 API 
Server 建立 连接 后 ， 会 用 Pod 里 指定 路 径 下 的 一 个 CA 证 书 
(/run/secrets/kubernetes.io/serviceaccount/ca.crt) 验证 API Server 
来 的 证 书 ， 验 证 是 否 是 被 CA 证 书签 名 的 合法 证 书 。 
API Server 收 到 这 个 Token 以 后 ， 采 用 目 己 的 私 钥 (实际 是 使 用 参 
数 service-account-key-file 指 定 的 私 钥 ， 如 果 此 参数 没有 设置 ， 则 
默认 采用 tls-private-key-file 指 定 的 参数 ， 即 自己 的 私 钥 ) 对 Token 
进行 合法 性 验证 。 


明白 了 认证 原理 ， 我 们 接 下 来 继续 分 析 上 面 认证 过 程 中 所 涉及 的 
Pod 中 的 以 下 三 个 文件 。 


e /run/secrets/kubernetes.io/serviceaccount/token ° 
e /run/secrets/kubernetes.io/serviceaccount/ca.crt ° 


e /run/secrets/kubernetes.io/serviceaccount/namespace (客户 端 采用 这 
里 指定 的 namespace 作 为 参数 调用 Kubernetes API) ° 


这 三 个 文件 由 于 参与 到 Pod 进 程 与 API Server 认 证 的 过 程 中 ， 起 到 
了 类 似 Secret (私密 凭据) 的 作用 ， 所 以 它们 被 称 为 Kubernetes Secret 
对 象 。Secret 从 属于 Service Account 资 源 对 象 ， 属 于 Service Account 的 
一 部 分 ， 一 个 Service Account 对 象 里 面 可 以 包括 多 个 不 同 的 Secret 对 
象 ， 分 别 用 于 不 同 目的 的 认证 活动 。 


下 面 我 们 通过 运行 一 些 命令 来 加 深 我 们 对 Service Account Secret 
的 直观 认识 2 


首先 ， 查 看 系统 中 的 Service Account 对象， 我 们 看 到 有 一 个 名 为 
default 的 Service Account 对 象 ， 包 含 一 个 名 为 default-token-77oyg 的 


Secret ， 这 个 Secret 同 时 是 “Mountable secrets”， 表 明 它 是 需要 被 Mount 
到 Pod 上 的 : 


# kubectl describe serviceaccounts 
Name: default 


Namespace: default 


Labels: <none> 

Image pull secrets: <none> 

Mountable secrets: default-token-770yg 
Tokens: default-token-770yg 


接 下 来 ， 我 们 看 看 default-token-77oyg 都 有 什么 内 容 : 


# kubectl describe secrets default-token-770yg 
Name: default-token-770yg 
Namespace: default 
Labels: «none» 
Annotations: kubernetes.io/service- 
account.name-default 
kubernetes.i0/service-account .uid=3e5b99c0- 


432c-11e6-b45c-000c29dc2102 
Type: kubernetes.io/service-account-token 


Data 


token: 


项 ， 


id, 


eyJhbGciOiJSUzI1NilsInR5cCIGOIkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldG 
VzL3NlcnzpY2VhY2Nvdw50Iiwia3ViZXJuZXRlcybpby9zZXJ2aWNlYWNjb 
aVudC9uYW1lc3BhY2UiOiJkZWZhdWxOIliwia3ViZXJuZXRlcy5pby9zZXJ2 
aWwNlIYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZzmFi1bHQtdG9rZzW4tNzdveWc 
iLCJrdwJlcm5ldGVzLmlvL3NlcnzpY2VhY2NvdW50L3NlcnZpY2UtYWNj b3 
VudC5uYW111IjoizGVmYXVsdCIsImtiYmVybmVOZXMuaW8vc2Vydml;jZWF jj Y 
291bnQvc2VydmljZS1hY2NvdW50LnVpZCI61jN1NWI5OWMwLTQzMmMtMTFl 
Ni1iNDVjLTAwMGMyOWRjMjEwMiIsInNi1Yil6InN5c3RlbTpzZXJ2aWN.lYWN 
jb3VudDpkZWZzhdWxOOmRlZzmFibHQifQ.MFsBrYmTLMB55X3UGfO pADP6GFS 
SQgHbOSxGJtTsJnY- 
ze2vFc8QdO7bVdmQfFbnkHgLWhti1KIpR EyvJTRP538uovgcA QGN9yIMEd 
qrIfQC2wfnLFuk10a80dSHAuzayBb50yI7gJWXWbXn6uOwAGMneiTKtCvzGf 
R4q- 
p19Jjh5qNPiUdJONhjsJJSAcihdNKA40XtOgMHdNNyPEmPgk60w2cM7DRb6i. 
FiSOsO5cTeLYviTpIBMvcQy4sYedCEL2cJ20BwcSo4- 
1Dev9rdxr50dtgCvo60xbPF7RcWwj jgUMLYO3YCiO7WmQNdmxWHJkwvBt kW 
ZhzdvuFCpHeWANA 

ca.crt: 1115 bytes 


namespace: 7 bytes 


从 上 面 的 输出 信息 中 我 们 看 到 ，default-token-77oyg 包 括 三 个 数据 


分 别 是 token、ca.crt、namespace。 联 想到 “Mountable secrets” 的 标 


以 及 之 前 看 到 的 Pod 中 的 三 个 文件 的 文件 名 ， 你 可 能 悦 然 大 人 悟 ， 


原来 是 这 么 一 回 事 : 每 个 Namespace 下 有 一 个 名 为 default 的 默认 的 
SerivceAccount 对 象 ， 这 个 SerivceAccount 里 面 有 一 个 名 为 Tokens 的 可 
以 当 作 Volume 一 样 被 Mount 到 Pod 里 的 Secret， 当 Pod 局 动 时 ， 


Secret 会 目 动 被 Mount 到 Pod 的 指定 目录 下 ， 用 来 协助 完成 Pod 中 的 进程 
访问 API Server 时 的 身份 鉴 权 过 程 。 


如 图 3.12 所 示 ， 一 个 Service Account 可 以 包括 多 个 Secret 对 象 。 


Secret 


在 service account 中 
用 于 访问 APl Server 
的 Secret 


在 service account 中 Secret 
用 于 下 载 image 的 
Secret 


3.12 Service Account 中 的 Secret 


(1) 名 为 Tokens 的 Secret 用 于 访问 API Server 的 Secret， 也 被 称 为 


Service Account Secret ° 


(2) 名 为 Inage pull secrets 的 Secret 用 于 下 载 容 器 镜像 时 的 认证 过 
程 ， 通 常 镜像 库 运 行 在 msecure 模 式 下 ， 所 以 这 个 Secret 为 空 。 


(3) 用 户 自 定义 的 其 他 Secret， 用 于 用 户 的 进程 。 


如 果 一 个 Pod 在 定义 时 没有 指定 spec.serviceAccountrName 属 性 ， 则 
系统 会 目 动 为 其 赋值 为 “default>， 即 大 家 都 使 用 同一 个 Namespace 下 默 
认 的 Service Account。 如 果 某 个 Pod 需 要 使 用 非 default 的 Service 
Account， 则 需要 在 定义 时 指定 : 


制 。 


apiVersion: vi 
kind: Pod 
metadata: 

name: mypod 
spec: 

containers: 

- name: mycontainter 
image: nginx:v1 


serviceAccountName: myserviceaccount 


Kubermetes 之 所 以 要 创建 两 套 独 立 的 账号 系统 ， 原 因 如 下 。 


User 账 号 是 给 人 用 的 ，Service Account 是 给 Pod 里 的 进程 使 用 的 ， 
面向 的 对 象 不 同 。 

User 账 号 是 全 局 性 的 ，Service Account 则 属于 某 个 具体 的 
Namespace ° 

ORL, User 5 E5 aint Pa ee PA, BE TT 
用 户 通常 要 走 一 套 复 杂 的 业务 流程 才能 实现 ，Service Account] 
创建 则 需要 极 轻 量 级 的 实现 方式 ， 集 群 管理 员 可 以 很 容易 为 某 些 
特定 任务 创建 一 个 Service Account 。 

对 于 这 两 种 不 同 的 账号 ， 其 审计 要 求 通常 不 同 。 

对 于 一 个 复杂 的 系统 来 说 ， 多 个 组 件 通 常 拥有 各 种 账号 的 配置 信 
A, Service Account 是 Namespace 隅 离 的 ， 可 以 针对 组 件 进 行 一 对 
一 的 定义 ， 同 时 有 具备 很 好 的 “便携 性 ”。 


接 下 来 ， 我 们 深入 分 析 Service Account 与 Secret 相 关 的 一 些 运 行 机 


BU H E^] Controller Manager 原 理 分 析 一 节 中 ， 我 们 知道 Controller 
manager 创 建 了 ServiceAccount Controller 与 Token Controller 两 个 安全 相 
KAH Hill as ° EL44ServiceAccount Controller 一 直 监 听 Service Account 和 
Namespace 的 事件 ， 如 果 一 个 Namespace 中 没有 default Service 
Account， 那 么 ServiceAccount Controller 束 会 为 该 Namespace 创 建 一 个 
默认 (default) A Service Account， 这 就 是 我 们 之 前 看 到 每 个 
Namespace 下 都 有 一 个 名 为 default 的 Service Account 的 原因 了 。 


如 有 果 Controller manager 进程 在 司 动 时 指定 了 API Server 4^ $H 

(service-account-private-key-file 参 数 ) ， 那 么 Controller manager 会 创 
建 Token Controller ° Token Controller 也 监听 Service Account 的 事件 ， 如 
果 发 现 新 创建 的 Service Account 里 没有 对 应 的 Service Account Secret, 
则 会 用 API Server 私 钥 创 建 一 个 Token (JWT Token) ， 并 用 该 Token、 
CA 证 书 及 Namespace 名 称 等 三 个 信息 产生 一 个 新 的 Secret 对 象 ， 然 后 放 
入 刚才 的 Service Account 中 ;如 采 监 听 到 的 事件 是 删除 Service Account 
事件 ， 则 自动 删除 与 该 Service Account 相 关 的 所 有 Secret。 此 外 ， 
Token Controller 对 象 同 时 监听 Secret 的 创建 、 修 改 和 删除 事件 ， 并 根据 
事件 的 不 同 做 不 同 的 处 理 。 


当 我 们 在 API Server 的 鉴 权 过 程 中 启用 了 Service Account 类 型 的 准 
入 控制 姻 ， 即 在 kube-apiserver 启 动 参数 中 包括 下 面 的 内 容 时 : 


--admission_control=ServiceAccount 


MET XT Pod ts BV IBAA K, Service Account 准 入 控制 器 会 验证 
Pod 里 的 Service Account 是 否 合 法 。 


(1) 如 果 spec.serviceAccount 域 没有 被 设置 ， 则 Kubernetes 默 认为 
其 指定 名 字 为 default 的 Service accout ° 


(2) 如 果 Pod 的 spec.serviceAccount 域 指定 了 default 以 外 的 Service 
Account， 而 该 Service Account 没 有 事先 被 创建 ， 则 该 Pod 操 作 失 败 。 


(3) 如 果 在 Pod 中 没有 指定 “ImagePullSecrets”， 那 么 这 个 
spec.serviceAccount 域 指定 的 Service Account 的 “ImagePullSecrets” 会 被 


加 入 该 Pod 中 。 


(4) 给 Pod 添 加 一 个 特殊 的 Volume， 在 该 Volume 中 包含 Service 
Account Secret 中 的 Token， 并 将 Volume 挂 载 到 Pod 中 所 有 容器 的 指定 目 


孙 下 (/var/run/secrets/kubernetes.io/serviceaccount) o 


Zk EPT, Service Account 的 正常 工作 离 不 开 以 下 几 个 控制 器 。 
(1) Admission Controller ° 
(2) Token Controller ° 


(3) ServiceAccount Controller ° 


3.6.5 ” Secret 私密 凭据 


上 一 万 我 们 提 到 Secret 对 象 ，Secret 的 主要 作用 是 保管 私密 数据 ， 
比如 密码 、OAuth Tokens、SSH Keys 等 信息 。 将 这 些 私 密 信息 放 在 
Secret 对 象 中 比 直 接 放 在 Pod 或 Docker Image 中 更 安全 ， 也 更 便于 使 用 
和 分 发 。 


下 面 的 例子 用 于 创建 一 个 Secret: 


secrets.yaml: 
apiVersion: vi 
kind: Secret 
metadata: 
name: mysecret 
type: Opaque 
data: 
password: dmFsdWUtMgOK 


username: dmFsdWUtMQOK 


# kubectl create -f secrets.yaml 


在 上 面 的 例子 中 ，data 域 的 各 子 域 的 值 必须 为 BASE64 编 码 值 ， 其 
中 password 域 和 username 域 BASE64 编码 前 的 值 分 别 为 “value- 
1 和 “value-2”。 


一 旦 Secret 被 创建 ， 则 可 以 通过 下 面 的 三 种 方式 使 用 它 。 


(1) 在 创建 Pod 时 ， 通 过 为 Pod 指 定 Service Account 来 自动 使 用 该 


Secret ° 
(2) 通过 挂 载 该 Secret 到 Pod 来 使 用 它 。 


(3) Docker 镜像 下 载 时 使 用 ， 通 过 指定 Pod 的 
spc.ImagePullSecrets 来 引用 它 。 


第 1 种 使 用 方式 主要 用 在 API Server 鉴 权 方面 ， 之 前 我 们 提 到 过 。 
下 面 的 例子 展示 了 第 2 种 使 用 方式 : 将 一 个 Secret 通 过 挂 载 的 方式 添加 
到 Pod 的 Volume 中 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

namespace: myns 

spec: 

containers: 

- name: mycontainer 
image: redis 
volumeMounts: 

- name: foo 
mountPath: "/etc/foo" 
readOnly: true 


volumes: 


- name: foo 
secret: 


secretName: mysecret 


其 结果 如 图 3.13 所 示 。 


图 3.13” 挂 载 Secret 到 Pod 


第 3 种 使 用 方式 的 使 用 流程 如 下 。 
(1) 执行 login 命 令 ， 登 录 私 有 Registry: 


# docker login localhost:5000 


输入 用 户 名 和 密码 ， 如 果 是 第 1 次 登录 系统 ， 则 会 创建 新 用 户 ， 


关 信 息 会 写 入 ~/.dockercfg 文 件 中 。 


(2) 用 BASE64 编 码 dockercfg 的 内 容 : 


相 


# cat ~/.dockercfg | base64 


(3) 将 上 一 步 命令 的 输出 结果 作为 Secret 的 “data.dockercfg” 域 的 
内 容 ， 由 此 来 创建 一 个 Secret: 


image-pull-secret.yaml: 
apiVersion: vi 
kind: Secret 
metadata: 

name: myregistrykey 
data: 

. dockercfg: 
eyAiaHROCHM6Ly9pbmRleC5kb2NrzXIuaW8vdjEvIjogeyAiYXVOaCI6ICJ 
abUZyWlhCaGMzTjNiMOprTVRJSyIsICJlbWFpbCI6ICJqZG91QGV4YWiwbG 
UuY29tIiB9IHOK 


type: kubernetes.io/dockercfg 


# kubectl create -f image-pull-secret.yaml 


(4) 在 创建 Pod 时 引用 该 Secret: 


pods.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 
name: mypod2 


spec: 


containers: 
- name: foo 
image: janedoe/awesomeapp: v1 
imagePullSecrets: 


- name: myregistrykey 


$ kubectl create -f pods.yaml 


其 结果 如 图 3.14 所 示 。 


myregistrykey 


3.14 imagePullSecret 引 用 Secret 


每 个 单独 的 Secret 大 小 不 能 超过 1MB Kubernetes# 8x 1] BEAR 
才 的 Secret， 因 为 如 果 使 用 大 尺寸 的 Secret， 则 将 大 量 占用 API Server 和 
kubelet 的 内 存 。 当 然 ， 创 建 许 多 小 的 Secret 也 能 耗 尽 API Server 和 
kubelet 的 内 存 。 


在 使 用 Mount 方 式 挂 载 Secret 时 ， Container Secret) “data” E HJ £& 
个 域 的 Key 值 作为 目录 中 的 文件 ，Value 值 被 BASE64 编 码 后 存储 在 相应 
的 文件 中 。 前 面 的 例子 中 创建 的 Secret， 被 挂 载 到 一 个 叫 作 mycontainer 


的 Container 中 ， 在 该 Container 中 可 通过 相应 的 查询 命令 查看 所 生成 的 
文件 和 文件 中 的 内 容 ， 如 下 所 示 : 


$ ls /etc/foo/ 

username 

password 

$ cat /etc/foo/username 
value-1 

$ cat /etc/foo/password 


value-2 


通过 上 面 的 例子 可 以 得 出 如 下 结论 : 我 们 可 以 通过 Secret 保 管 其 他 
系统 的 敏感 信息 〈 比 如 数据 库 的 用 户 名 和 密码 ) ， 并 以 Mount 的 方式 
将 Secret 挂 载 到 Container 中 ， 然 后 通过 访问 目录 中 的 文件 的 方式 获取 该 
敏感 信息 。 当 Pis ioni 建 时 ，API Server 不 会 校 验 该 Pod 引 用 
的 Secret 是 否 存 在 。 个 Pod 被 调度 ， 则 kubelet 将 斌 着 获取 Secret 的 
值 。 e P s Server， 则 kubelet 将 按 一 
定 的 时 间 间 隔 定 期 重 试 获取 该 Secret， 并 发 送 一 个 Event 来 解释 Pod 没 有 
启动 的 原因 。 一 旦 Secret 被 Pod 获 取 ， 则 kubelet 将 创建 并 Mount 包 含 
Secret 的 Volume。 只 有 所 有 Volume 被 Mount 后 ，Pod 中 的 Container 才 会 
被 启动。 在 kubelet 启 动 Pod 中 的 Container 后 ，Container 中 的 和 Secret 相 
关 的 Volume 将 不 会 被 改变 ， 即 使 Secret 本 身 被 修改 了 。 为 了 使 用 更 狐 
后 的 Secret， 必 须 删 除 旧 的 Pod， 并 重新 创建 一 个 新 的 Pod， 因 此 更 新 
Secret 的 流程 和 部 署 一 个 新 的 Image 是 一 样 的 。 


3.7 ”网 络 原理 


关于 Kubernetes 网 络 ， 我 们 通常 有 这 些 问 题 需 要 回答 ， 如 图 3.15 所 


Kubernetes 的 网 络 模型 是 什么 | 
Docker 背后 的 网 络 基 础 是 什么 | 
Docker 自身 的 网 络 模型 和 局 限 

Kubernetes 的 网 络 组 件 之 间 是 怎么 通信 的 


外 部 如 何 访问 Kubernetes 的 集群 
有 哪些 开源 的 组 件 支 持 Kubernetes 的 网 络 模型 


[3.15 ”Kubernetes 的 常见 问题 


在 本 节 我 们 分 别 回答 这 些 问题 ， 然 后 通过 一 个 具体 的 实验 来 将 这 
些 相关 的 知识 串联 成 一 个 整体 。 


3.7.1 Kubernetes 网 络 模 型 


Kubernetes 网 络 模型 设计 的 一 个 基础 原则 是 : 每 个 Pod 都 拥有 一 个 
独立 的 下地 址 ， 而 且 假 定 所 有 Pod 都 在 一 个 可 以 直接 连通 的 、 忆 平 的 网 
络 空间 中 。 所 以 不 管 它们 是 否 运行 在 同一 个 Node (MEJ) 中， 都 要 
求 它们 可 以 直接 通过 对 方 的 IP 进 行 访问 。 设 计 这 个 原则 的 原因 是 ， 用 
户 不 需要 额外 考虑 如 何 建 六 Pod 之 则 的 连接 ， 也 不 需要 考虑 将 容 絮 端 
口 映 射 到 主机 端口 等 问题 。 


实际 上 在 Kubernetes 的 世界 里 ， 卫 是 以 Pod 为 单位 进行 分 配 的 。 一 
个 Pod 内 部 的 所 有 容器 共享 一 个 网 络 堆栈 《实际 上 就 是 一 个 网 络 命名 
空间 ， 包 括 它 们 的 IP 地 址 、 网 络 设备 、 配 置 等 都 是 共享 的 ) 。 按 照 这 
个 网 络 原则 抽象 出 来 的 一 个 Pod 一 个 JP 的 设计 模型 也 被 称 作 IP-per-Pod 
模型 。 


由 于 Kubernetes 的 网 络 模型 假设 Pod 之 间 访 问 时 使 用 的 是 对 方 Pod 
的 实际 地 址 ， 所 以 一 个 Pod 内 部 的 应 用 程序 看 到 的 目 己 的 卫 地 址 和 端口 
与 集群 内 其 他 Pod 看 到 的 一 样 。 它 们 都 是 Pod 实 际 分 配 的 IP 地 址 (从 
docker0 上 分 配 的 ) 。 将 IP 地 址 和 端口 在 Pod 内 部 和 外 部 都 保持 一 致 ， 
我 们 可 以 不 使 用 NAT 来 进行 转换 ， 地 址 空间 也 目 然 是 平 的 。Kubernetes 
的 网 络 之 所 以 这 么 设计 ， 主 要 原因 就 是 可 以 兼容 过 去 的 应 用 。 当 然 ， 
我 们 使 用 Linux 命 令 “ip addr show” 也 能 看 到 这 些 地 址 ， 和 程序 看 到 的 没 
有 什么 区 别 。 所 以 这 种 IP-per-Pod 的 方案 很 好 地 利用 了 现 有 的 各 种 域名 
解析 和 发 现 机 制 。 


—“SPod—“MIPHIRALAA AS, BER — T Pod A Hy 
AN Vil Bea RF ES — SP 28 a 88], He] — Linx 428 DX 
T ^ RAR [8] — T Pod P] 88 n] CA localhost Ri BOX] 77 A Sia 
口 。 这 种 关系 和 同一 个 VM 内 的 进程 之 间 的 关系 是 一 样 的 ， 看 起 来 Pod 
内 的 容器 之 间 的 隔离 性 降低 了 ， 而 且 Pod 内 不 同 容 禹 之 间 的 端口 是 共 
享 的 ， 没 有 所 谓 的 和 有 端口 的 概念 了 。 如 采 你 的 应 用 必须 要 使 用 一 些 
特定 的 端口 范围 ， 那 么 你 也 可 以 为 这 些 应 用 单独 创建 一 些 Pod。 反 
之 ， 对 那些 没有 特殊 需要 的 应 用 ， 这 样 做 的 好 处 是 Pod 内 的 容器 十 共 
诗 部 分 资源 的 ， 通 过 共 至 资源 互相 通信 和 显然 更 加 容易 和 高 效 。 针 对 这 
些 应 用 ， 虽 然 损 失 了 可 接受 范围 内 的 部 分 隔离 性 ， 但 也 十 值得 的 。 


IP-per-Pod 模 式 和 Docker 原 生 的 通过 动态 端口 映射 方式 实现 的 多 市 
点 访问 模式 有 什么 区 别 呢 ? 主要 区 别 是 后 者 的 动态 端口 映射 会 引入 端 
口 管 理 的 复杂 性 ， 而 且 访 问 者 看 到 的 耳 地 址 和 端口 与 服务 提供 者 实际 
绑 定 的 不 同 〈 因 为 NAT 的 缘故， 它们 都 被 映射 成 新 的 地 址 或 端口 
了 ) ， 这 也 会 引起 应 用 配置 的 复杂 化 。 同 时 ， 标 准 的 DNS 等 名 字 解 析 
服务 也 不 适用 了 。 甚 至 服务 注册 和 发 现 机 制 都 将 受到 挑战 ， 因 为 在 端 
口 映 射 情况 下 ， 服 务 目 生 很 难 知道 目 己 对 外 骏 露 的 真实 的 服务 了 P 和 端 
口 。 而 外 部 应 用 也 无 法 通过 服务 所 在 容 需 的 私有 卫 地 址 和 端口 来 访问 


服务 。 


总 的 来 说 ，IP-per-Pod 模 型 是 一 个 简单 的 兼容 性 较 好 的 模型 。 从 该 
模型 的 网 络 的 端口 分 配 、 域 名 解析 、 服 务 发 现 、 负 载 均 衡 、 应 用 配置 
和 迁移 等 角度 来 看 ，Pod 都 能 够 被 看 作 一 台独 立 的 “虚拟 机 * 或 "物理 
机 ”。 


按照 这 个 网 络 抽象 原则 ，Kubernetes 对 网 络 有 什么 前 提 和 要 求 
WE? 


Kubernetes 对 集群 的 网 络 有 如 下 要 求 : 


(1) 所 有 容 眉 都 可 以 在 不 用 NAT 的 方式 下 同 别 的 容器 通信 ; 


(2) 所 有 市 点 都 可 以 在 不 用 NAT 的 方式 下 同 所 有 容器 通信 ， 反 之 


(3) 容器 的 地 址 和 别人 看 到 的 地 址 是 同一 个 地 址 。 


这 些 基本 的 要 求 意 味 着 并 不 是 只 了 两 台 机 需 运 行 Docker , 
Kubernetes 就 可 以 工作 了 。 具 体 的 集群 网 络 实现 必须 保障 上 述 基 本 要 
求 ， 原 生 的 Docker 网 络 目前 还 不 能 很 好 地 文 持 这 些 要 求 。 


实际 上 ， 这 些 对 网 络 模型 的 要 求 并 没有 降低 整个 网 络 系统 的 复杂 
度 。 如 果 你 的 程序 原来 在 VM 上 运行 ， 而 那些 VM 拥 有 独立 IP， 并 且 它 
们 之 间 可 以 直接 透明 地 通信 ， 那 么 Kubernetes 的 网 络 模 型 就 和 VM 使 用 
的 网 络 模型 是 一 样 的 。 所 以 使 用 这 种 模型 可 以 很 容易 地 将 已 有 的 应 用 
程序 从 VM 或 者 物理 机 迁移 到 容器 上 。 


当然 ， 合 歌 设 计 Kubernetes 的 一 个 主要 运行 基础 就 是 其 云 环 境 
GCE (Google Compute Engine) ， 在 GCE 下 这 些 网 络 要 求 都 是 默认 支 
持 的。 另外 ， 常 见 的 其 他 公有 云 服务 商 如 亚马逊 等 ， 在 它们 的 公有 云 
计算 环境 下 也 是 默认 支持 这 个 模型 的 。 


由 于 部 署 私 有 云 的 场景 会 更 普 笛 ， 所 以 在 私有 云 中 运行 
Kubernetes+DockerS2## Z BU, Sms 2A CYS = T Kubernetes 22 5K 
的 网 络 环境 。 现 在 的 开源 世界 有 很 多 开源 组 件 可 以 帮助 我 们 打通 
Docker 容 需 和 容 事 之 间 的 网 络 ， 实 现 Kubernetes 要 求 的 网 络 模型 。 当 然 


每 种 方案 都 有 适合 的 场景 ， 我 们 要 根据 目 己 的 实际 需要 进行 选择 。 在 
后 面 的 章节 中 会 对 第 见 的 开源 方案 进行 介绍 。 


Kubemetes 的 网 络 依赖 于 Docker，Docker 的 网 络 叉 离 不 开 Linux 操 
作 系 统 内 核 特 性 的 支持 ， 所 以 我 们 有 必要 先 深 入 了 解 Docker 背 后 的 网 
络 原 理 和 基础 知识 。 接 下 来 我 们 一 起 深入 学 习 一 些 必 要 的 Linux 网 络 知 


识 。 


ZN 


3.7.2 ”Docker 的 网 络 基础 


Docker 本 身 的 技术 依赖 于 近年 Linux 内 核 虚 拟 化 技术 的 发 展 ， 所 以 
Docker 对 Linux 内 核 的 特性 有 很 强 的 依赖 。 这 里 将 Docker 使 用 到 的 与 
Linux 网 络 有 关 的 主要 技术 进行 简要 介绍 ， 这 些 技术 包 括 如 下 几 种 ， 如 
图 3.16 所 示 。 


Network Namespace ( 网络 命名 空间 | 
Veth 设备 对 | 
Iptables/Netfilter | 
网 桥 | 
路 由 | 


A43.16 ”Docker 使 用 到 的 与 Linux 网 络 有 关 的 主要 技术 


1. 网 络 的 命名 空间 


为 了 支持 网 络 协议 栈 的 多 个 实例 ，Linux 在 网 络 栈 中 引入 了 网 络 命 
名 空间 (Network Namespace) ， 这 些 独 立 的 协议 栈 被 隔离 到 不 同 的 命 
名 空间 中 。 处 于 不 同 命名 空 i de, 彼此 之 间 无 法 
通信 ， 就 好 像 两 个 “平行 宇宙 ”。 通 过 这 种 对 网 络 资源 的 隔离 ， 束 能 在 
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在 Linux 的 网 络 命名 空间 内 可 以 有 目 己 独立 的 路 由 表 及 独立 的 
Iptables/Netfilter 设 置 来 提供 包 转 发 、NAI 及 IP 包 过 滤 等 功能 。 


为 了 隔离 出 独立 的 协议 栈 ， 需 要 纳入 命名 空间 的 元 素 有 进程 、 套 
接 字 、 网 络 设备 等 。 进 程 创建 的 套 接 字 必 须 属于 茶 个 命名 空间 ， 套 接 
字 的 操作 也 必须 在 命名 空间 内 进行 。 同 样 ， 网 络 设备 也 必须 属于 某 个 
命名 空间 。 因 为 网 络 设备 属于 公共 资源 ， 所 以 可 以 通过 修改 属性 实现 
在 命名 空间 之 间 移 动 。 当 然 ， 是 否 允 许 移动 和 设备 的 特征 有 关 。 


让 我 们 稍微 深入 Linux 操 作 系 统 内 部 ， 看 它 是 如 何 实 现 网 络 命 名 空 
间 的 ， 这 也 会 对 理解 后 面 的 概念 有 帮助 。 


) 网 络 命 名 空间 的 实现 


Linux 的 网 络 协议 栈 是 十 分 复杂 的 ， 为 了 文 持 独立 的 协议 栈 ， 相 关 
的 这 些 全 局 变量 都 必须 修改 为 协议 栈 私 有 “。 最 好 的 办 法 束 是 让 这 些 全 
局 变量 成 为 一 个 Net Namespace 变 量 的 成 员 ， 然 后 为 协议 栈 的 函数 调用 
加 入 一 个 Namespace 参 数 。 这 就 是 Linux 实 现 网 络 命名 空间 的 核心 。 


同时 ， Doc HH A 内 

核 代码 隐 式 地 使 用 了 命名 空间 内 的 变量 。 我 们 的 程序 如 果 没 有 对 命名 

空间 的 特殊 需求 ， RA mtem. 网 络 命名 空间 对 应 用 程 
序 而 言 是 透明 的 。 


在 建立 了 新 的 网 络 命名 空间 ， 并 将 某 个 进程 关联 到 这 个 网 络 命名 
空间 后 ， 就 出 现 了 类 似 于 如 图 3.17 所 示 的 内 核 数 据 结构 ， 所 有 网 站 栈 


变量 都 放 入 了 网 络 命名 空间 的 数据 结构 中 。 这 个 网 络 命 名 空间 征 属于 
它 的 进程 组 私有 的 ， 和 其 他 进程 组 不 冲突 。 


新 生成 的 私有 命名 空间 只 有 回环 lo 设备 (而且 是 停止 状态 ) ， 其 
他 设备 默认 都 不 存在 ， 如 果 我 们 需要 ， 则 要 一 一 手工 建立 。Docker 容 
器 中 的 各 类 网 络 栈 设备 都 是 Docker Daemon 在 启动 时 自动 创建 和 配置 
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所 有 的 网 络 设备 (物理 的 或 虚拟 接口 、 桥 等 在 内 核 里 都 叫 作 
NetDevice) 都 只 能 属于 一 个 命名 空间 。 当 然 ， 通常 物理 的 设备 (连接 
实际 硬件 的 设备 ) 只 能 关联 到 root 这 个 命名 空间 中 。 虚 拟 的 网 络 设备 

(虚拟 的 以 太 网 接口 或 者 虚拟 网 口 对 ) 则 可 以 被 创建 并 关联 到 一 个 给 
定 的 命名 空间 中 ， 而 且 可 以 在 这 些 命 名 空间 之 间 移 动 。 


名 字 空 间 : -H 


进程 


进程 — i 一 


图 3.17 命名 空间 内 核 结构 


前 面 我 们 提 到 ， 由 于 网 络 命名 空间 代表 的 是 一 个 独立 的 协议 栈 ， 
所 以 它们 之 间 十 相互 隔离 的 ， 彼 此 无 法 通信 ， 在 协议 栈 内 部 都 看 不 到 
对 方 。 那么 有 没有 办 法 打破 这 种 限制 ， 让 处 于 不 同 命 名 空间 的 网 络 相 


互通 信 ， 甚 至 和 外 部 的 网 络 进行 通信 呢 ? AW Veth ix A 
RI* « "Vett PORE ERFARE EAE DEA IR 
HEE, "EUER T B Y. —AEREBIXCT AE Ds 28 TA) , 
问 连 着 男 一 个 网 络 命 名 空间 的 协议 栈 。 所 以 如 采 想 在 两 个 命名 空间 之 
间 进 行 通信 ， 就 必须 有 一 个 Veth 设 备 对 。 后 面 我 们 会 介绍 如 何 操作 
Veth 设 备 对 来 打通 不 同 命名 空间 之 间 的 网 络 。 


) 网 络 命名 空间 操作 
下 面 列举 一 些 网 络 命 名 空间 的 操作 。 


我 们 可 以 使 用 Linux iproute2 系 列 配 置 工具 中 的 IP 命 令 来 操作 网 络 
命名 空间 。 注 意 ， 这 个 命令 需要 由 root 用 户 运 行 。 


创建 一 个 命名 空间 : 


ip netns add <name> 


在 命名 空间 内 执行 命 


ip netns exec <name><command> 


如 果 想 执行 多 个 命令 ， 则 可 以 先进 入 内 部 的 sh， 然 后 执行 : 


ip netns exec <name> bash 
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时 ， 请 输入 “exit”。 


) 网 络 命 名 空间 的 一 些 技 巧 
操作 网 络 命 名 空间 时 的 一 些 实用 技巧 如 下 。 


A ee gee ea 
的 Veth 设 备 对 的 转移 。 因 为 一 个 设备 只 能 属于 一 个 命名 空间 ， 所 以 转 
移 后 在 这 个 命名 空间 内 就 看 不 到 这 个 设备 了 。 Pee BE 够 转移 
到 不 同 的 命名 空间 呢 ? 在 设备 里 面 有 一 个 重要 的 属性 
NETIF F_ ETNS_LOCAL ， 如 果 这 个 属性 为 “on”， 则 不 能 转移 到 其 他 
命名 空间 内 。Veth 设 备 属于 可 以 转移 的 设备 ， 而 很 多 其 他 设备 如 lo 设 
备 、vxlan 设 备 、ppp 设 备 、bridge 设 备 等 都 是 不 可 以 转移 的 。 至 于 将 无 
法 转移 的 设备 移动 到 别 的 命名 空间 的 操作 ， 则 会 得 到 无 效 参 数 的 错误 
提示 。 


# ip link set brO netns nsi 


RTNETLINK answers: Invalid argument 


如 何 知 道 这 些 设 备 是 否 可 以 转移 呢 ? 可 以 使 用 ethtool 工 具 查 看 : 


# ethtool -k bro 


netns-local: on [fixed] 


netns-local 的 值 是 on， 束 说明 不 可 以 转移 ， 否 则 可 以 。 


2.Veth 设 备 对 


引入 Veth 设 备 对 是 为 了 在 不 同 的 网 络 命名 空间 之 间 进 行 通信 ， 利 
用 它 可 以 直接 将 两 个 网 络 命 名 空间 连接 起 来 。 由 于 要 连接 两 个 网 络 命 


ARE, BTDAVethiót & aie BOY EWA, ARO OA, HEF 
[A] A — AR ELXEBU SIZE, « BERETS, BARIERE RY 


WE A 
一 端的 peer。 在 Veth 设 备 的 一 端 发 送 数据 时 ， 它 会 将 数据 直接 发 送 到 
另 一 端 ， 并 触发 另 一 端的 接收 操作 。 


整个 veth 的 实现 非常 简单 ， 有 兴趣 的 读者 可 以 参考 源 代 
码 “drivers/net/Veth.c” 的 实现 。 图 3.18 是 Veth 设 备 对 的 示意 图 。 
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图 3.18 eth 设 备 对 示意 图 
1) Veth 设 备 对 的 操作 命令 


接 下 来 看 看 如 何 创建 Veth 设 备 对 ， 如 何 连接 到 不 同 的 命名 空间 ， 
并 设置 它们 的 地 址 ， 让 它们 通信 。 


创建 Veth 设 备 对 : 


ip link add vethO type veth peer name veth1 


创建 后 ， 可 以 查看 veth 设 备 对 的 信息 。 使 用 ip link show 命 令 查看 
所 有 网 络 接口 : 


# ip link show 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN mode DEFAULT 
Link/loopback:  00:00:00:00:00:00 brd 
00:00:00:00:00:00 
2: eno16777736: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 
1500 qdisc pfifo fast state UP mode DEFAULT qlen 1000 
link/ether 00:0c:29:cf:1a:2e brd ff:ff:ff:ff:ff:ff 
3: docker0O: <NO-CARRIER, BROADCAST, MULTICAST,UP» mtu 
1500 qdisc noqueue state UP mode DEFAULT 
link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff 
19: vethi1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
state DOWN mode DEFAULT qlen 1000 
link/ether 7e:4a:ae:41:a3:65 brd ff:ff:ff:ff:ff:ff 
20: vethO: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
state DOWN mode DEFAULT qlen 1000 
link/ether ea:da:85:a3:75:8a brd ff:ff:ff:ff:ff:ff 


看 到 了 吧 ， 有 两 个 设备 生成 了 ， 一 个 是 veth0， 它 的 peer 是 veth1 ° 


现在 这 两 个 设备 都 在 目 己 的 命名 空间 内 ， 那 怎么 能 行 呢 ? ET, 
如 果 将 Veth 看 作 有 两 个 头 的 网 线 ， 那 么 我 们 将 另 一 个 头 甩 给 夯 一 个 命 


名 空间 吧 .: 


ip link set vethi netns netns1 
这 时 可 在 外 面 这 个 命名 空间 内 看 两 个 设备 的 情况 : 


# ip link show 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN mode DEFAULT 
Link/loopback:  00:00:00:00:00:00  brd 
00:00:00:00:00:00 
2: eno16777736: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 
1500 qdisc pfifo fast state UP mode DEFAULT qlen 1000 
link/ether 00:0c:29:cf:1a:2e brd ff:ff:ff:ff:ff:ff 
3: docker0O: <NO-CARRIER, BROADCAST,MULTICAST,UP> mtu 
1500 qdisc noqueue state UP mode DEFAULT 
link/ether 56:84:7a:fe:97:99 brd ff:ff: ff: ff: fF: fF 
20: vethO: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
state DOWN mode DEFAULT glen 1000 


link/ether ea:da:85:a3:75:8a brd ff: ff: ff: FF: FF: FF 


只 剩 一 个 veth0 设 备 了 ， 已 经 看 不 到 另 一 个 设备 了 ， 另 一 个 设备 已 
经 转移 到 另 一 个 网 络 命名 空间 了 。 


在 netns1 网 络 命名 空间 中 可 以 看 到 veth1 设 备 了 ， 符 合 预期 。 


# ip netns exec netns1 ip link show 


1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 


state UNKNOWN mode DEFAULT 
Link/loopback:  00:00:00:00:00:00  brd 
00:00:00:00:00:00 
19: vethi: <BROADCAST,MULTICAST> mtu 1500 qdisc noop 
state DOWN mode DEFAULT glen 1000 
link/ether 7e:4a:ae:41:a3:65 brd ff:ff: ff: ff: fF: ff 


现在 看 到 的 结果 是 ， 两 个 不 同 的 命名 空间 各 和 目 有 一 个 Veth 的 “网 线 
头 ”， 各 显示 为 一 个 Device (在 Docker 的 实现 里 面 ， 它 除了 将 Veth 放 入 
容 如 内， 还 将 它 的 名 字 改 成 了 eth0， 简 直 以 假 乱 真 ， 你 以 为 它 是 一 个 
本 地 网 卡 吗 ) 。 


现在 可 以 通信 了 吗 ? 不 行 ， 因 为 它们 还 没有 任何 地 址 ， 现 在 我 们 
来 给 它们 分 配 卫 地 址 吧 : 


ip netns exec netnsi1 ip addr add 10.1.1.1/24 dev veth1 


ip addr add 10.1.1.2/24 dev vethO 


再 局 动 它们 : 


ip netns exec netns1 ip link set dev vethi up 


ip link set dev vethO up 


现在 两 个 网 络 命名 空间 可 以 互相 通信 了 : 


# ping 10.1.1.1 
PING10.1.1.1 (10.1.1.1) 56(84) bytes of data. 


64 bytes from 10.1.1.1: icmp seq-1 ttl-64 time=0.035 


ms 


ms 


time 


ms 


ms 


time 


64 bytes from 10.1.1.1: icmp seq-2 ttl-64 time-0.096 


^C 
--- 10.1.1.1 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, 


1001ms 


rtt min/avg/max/mdev = 0.035/0.065/0.096/0.031 ms 


# ip netns exec netnsi ping 10.1.1.2 
PING10.1.1.2 (10.1.1.2) 56(84) bytes of data. 


64 bytes from 10.1.1.2: icmp seq-1 ttl-64 time-0.045 


64 bytes from 10.1.1.2: icmp seq-2 ttl-64 time-0.105 


^C 
--- 10.1.1.2 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, 


1000ms 


rtt min/avg/max/mdev = 0.045/0.075/0.105/0.030 ms 
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至 此 我 们 惑 能 够 理解 Veth 设 备 对 的 原理 和 用 法 了 。 在 Docker 内 
Veth 设 备 对 也 十 联系 容 船 到 外 面 的 重要 设备 ， 离 开 它 征 不 行 的 。 


2) Veth 设 备 对 如 何 查看 对 端 


我 们 在 操作 Veth 设 备 对 的 时 候 有 一 些 实用 技巧 ， 如 下 所 示 。 


一 旦 将 Veth 设 备 对 的 peer 端 放 入 男 一 个 命名 空间 ， 我 们 在 本 命名 
空间 内 就 看 不 到 它 了 。 那 么 我 们 怎么 知道 这 个 Veth 对 的 对 端 在 哪里 
呢 ， 也 就 是 说 它 到 底 连 接 到 哪个 别 的 命名 空间 呢 ? 可 以 使 用 ethtool 工 
具 来 查看 〈 当 网 络 命名 空间 特别 多 的 时 候 ， 这 可 不 是 一 件 很 容易 的 事 


情 ) 


目 先 我 们 在 一 个 命名 空间 中 查询 Veth 设 备 对 端 接口 在 设备 列表 中 
的 序列 与 : 


ip netns exec netnsi ethtool -S vethi 
NIC statistics: 


peer ifindex: 5 


得 知 男 一 端的 接口 设备 的 序列 号 是 5， 我 们 再 到 为 一 个 命名 空间 中 
查看 序列 号 5 代表 什么 设备 : 


ip netns exec netns2 ip link | grep 5 «-- 我 们 只 关注 
序列 号 是 5 的 设备 
vetho 
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HAMER AMAER RUvethl 了， 因为 它们 互 为 peer ° 


3. 网 桥 


Linux 可 以 支持 很 多 不 同 的 端口 ， 这 些 端 口 之 间 当 然 应 该 能 够 通 
信 ， 如 何 将 这 些 端口 连接 起 来 并 实现 类 似 交 换 机 那样 的 多 对 多 通信 
We? 这 就 是 网 桥 的 作用 了 “。 网 桥 是 一 个 二 层 网 络 设备 ， 可 以 解析 收发 
的 报 文 ， 读 取 目 标 MAC 地 址 的 信息 ， 和 上 自己 记录 的 MAC 表 结合 ， 来 
决策 报 文 的 转发 端口 。 为 了 实现 这 些 功能 ， 网 桥 会 学 习 源 MAC 地 址 
(二 层 网 桥 转 发 的 依据 就 是 MAC 地 址 ) 。 在 转发 报 文 的 时 候 ， 网 桥 只 
需要 向 特 定 的 网 络 接口 进行 转发 ， 从 而 避免 不 必要 的 网 络 交 互 。 如 果 
它 遇 到 一 个 自己 从 未 学 习 到 的 地 址 ， 就 无 法 知道 这 个 报 文 应 该 从 哪个 
网 口 设 备 转 发 ， 于 是 只 好 将 报 文 广播 给 所 有 的 网 络 设备 端口 〈 报 文 来 
源 的 那个 端口 除外 ) 。 


在 实际 网 络 中 ， 网 络 拓扑 不 可 能 永久 不 变 。 如 采 设 备 移动 到 另 一 
个 端口 上 ， 而 它 没 有 发 送 任何 数据 ， 那 么 网 桥 设 备 吕 无 法 感知 到 这 个 
变化 ， 结 有 末 网 桥 还 是 同 原 来 的 端口 转发 数据 包 ， 在 这 种 情况 下 数据 束 
会 丢失 。 所 以 网 桥 还 要 对 学 习 到 的 MAC 地 址 表 加 上 超时 时 间 (默认 为 
5 分 钟 ) 。 如 果 网 桥 收 到 了 对 应 端口 MAC 地 址 回 发 的 包 ， 则 重 置 超时 
时 间 ， 否 则 过 了 超时 时 间 后 ， 束 认为 那个 设备 已 经 不 在 那个 端口 上 
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在 Linux 的 内 部 网 络 栈 里 面 实现 的 网 桥 设 备 ， 作 用 和 上 面 的 描述 相 
° 过 去 Linux 主 机 一 般 都 只 有 一 个 网 卡 ， 现 在 多 网 卡 的 机 妖 越 来 越 
， 而 且 还 有 很 多 虚拟 的 设备 存在 ， 所 以 Linux 的 网 桥 提 供 了 这 些 设备 
间 互 相 转 发 数据 的 二 层 设备 。 


N 


Linux 内 核 文 持 网 口 的 桥接 (目前 只 支持 以 太 网 接口 。 但 是 与 单 
纯 的 交换 机 不 同 ， 交 换 机 只 是 一 个 二 层 设 备 ， 对 于 接收 到 的 报 文 ， 要 
么 转发 ， 要 和 丢弃。 运行 着 Linux 内 核 的 机 器 本 身 束 是 一 台 主 机 ， 有 可 
能 十 网 络 报 文 的 目的 地 ， 其 收 到 的 报 文 除 了 转发 和 丢弃 ， 还 可 能 被 送 


到 网 络 协 议 栈 的 上 层 (网 络 层 ) ， 从 而 被 自己 〈 这 人 台 主 机 本 身 的 协议 
栈 ) 消化 ， 所 以 我 们 既 可 以 把 网 桥 看 作 一 个 二 层 设备 ， 也 可 以 看 作 一 


个 三 层 设 备 。 
1) Linux 网 桥 的 实现 


Linux 内 核 是 通过 一 个 虚拟 的 网 桥 设备 (Net Device) 来 实现 桥接 
的 。 这 个 虚拟 设备 可 以 绑 定 若干 个 以 太 网 接口 设备 ， 从 而 将 它们 桥接 
起 来 。 如 图 3.19 所 示 ， 这 种 Net Device 网 桥 和 普通 的 设备 不 同 ， 最 明显 
的 一 个 特性 是 它 还 可 以 有 一 个 IP 地 址 。 


dev queue xmit ] netif receive skb ] 


i» gest ] NIC device drivers | 


图 3.19 网 桥 的 位 置 


如 独 3.19 所 示 ， 网 桥 设 备 br0 绑 定 了 eth0 和 eth1。 对 于 网 络 协议 栈 的 
上 层 来 说 ， 只 看 得 到 pr0。 因 为 桥接 是 在 数据 链 路 层 实 现 的 ， 上 属 不 需 
要 关心 桥接 的 细节 ， 于 是 协议 栈 上 层 需要 发 送 的 报 文 被 送 到 br0， 网 桥 
设备 的 处 理 代 码 判断 报 文 该 被 转发 到 eth0 还 是 eth1， 或 者 两 者 乡 转 发 ; 


有 反 过 来 ， 从 eth0 或 从 eth1 接 收 到 的 报 文 被 提交 给 网 桥 的 处 理 代码 ， 在 这 
里 会 判断 报 文 应 该 被 转发 、 丢 弃 还 是 提交 到 协议 栈 上 层 。 


而 有 时 eth0、eth1 也 可 能 会 作为 报 文 的 源 地 址 或 目的 地 址 ， 直 接 参 
与 报 文 的 发 送 与 接收 ， 从 而 绕 过 网 桥 。 


2) 网 桥 的 利用 操作 命令 


Docker 目 动 完 成 了 对 网 桥 的 创建 和 维护 。 为 了 进一步 理解 网 桥 ， 
下 面 举 几 个 党 用 的 网 桥 操作 例子 ， 对 网 桥 进 行 手工 操作 : 


#brctl addbr xxxxx 就 是 新 增 一 个 网 桥 


之 后 可 以 增加 问 口 ， 在 Linux 中 ， 一 个 端口 其 实 克 是 一 个 物理 网 
卡 。 将 物理 网 卡 和 网 桥 连接 起 来 : 


Zbrctl addif xxxxx ethx 


网 桥 的 物理 网 卡 作为 一 个 端口 ， 由 于 在 链 路 层 工作 ， 就 不 再 需要 
IP 地 址 了 ， 这 样 上 面 的 IP 地 址 上 自然 失效 : 


#ifconfig ethx 0.0.0.0 


给 网 桥 配置 一 个 IP 地 址 : 


#ifconfig brxxx XXXx.XXX.XXX.XXX 


这 样 网 桥 束 有 了 一 个 了 地 址 ， 而 连接 到 上 面 的 网 卡 殉 是 一 个 纯 链 
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在 Linux 网 络 协议 栈 中 有 一 组 回调 函数 挂 拨 点 ， 通 过 这 些 挂 接点 挂 
接 的 钩子 函数 可 以 在 Linux 网 络 栈 处 理 数据 包 的 过 程 中 对 数据 包 进 行 一 
些 操 作 ， 例 如 过 滤 、 修 改 、 丢 弃 等 。 整 个 挂 接点 技术 叫 作 Netfilter 和 
Iptables ° 
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而 Iptables 征 在 用 户 模 式 下 运行 的 进程 ， 负 责 协 助 维护 内 核 中 Netfilter 
的 各 种 规则 表 。 通 过 二 者 的 配合 来 实现 整个 Linux 网 络 协议 栈 中 灵活 的 
数据 包 处 理 机 制 。 


Netfilter 可 以 挂 接 的 规则 点 有 5 个 ， 如 图 3.20 中 的 深 色 椭圆 所 示 。 


上 层 协议 处 理 | 


xd S 
< 中 由 > 
SS 
SS 
< oru = FORWARD 25 
POSTROUTING 


| 接口 设备 


图 3.20 ”Netfilter 挂 接点 
1) 规则 表 Table 


这 些 挂 接点 能 挂 接 的 规则 也 分 不 同 的 类 型 (也 就 是 规则 表 
Table) ， 我 们 可 以 在 不 同类 型 的 Table 中 加 入 我 们 的 规则 。 目 前 主要 支 
持 的 Table 类 型 为 : 


e RAW; 

e MANGLE; 
e NAT; 

e FILTER ° 


-Exü4^ Table (规则 链 ) 的 优先 级 是 RAW 最 高 ，FILTER 最 低 。 


在 实际 应 用 中 ， 不 同 的 挂 接点 需要 的 规则 类 型 通常 不 同 。 例 如 ， 
在 input 的 挂 接点 上 明显 不 需要 FILTER 过 滤 规 则 ， 因 为 根据 目标 地 址 ， 
已 经 选择 好 本 机 的 上 层 协议 栈 了 ， 所 以 无 须 再 挂 接 FILTER 过 滤 规 则 © 
目前 Linux 系 统 支 持 的 不 同 挂 接 点 能 挂 接 的 规则 类 型 如 图 3.21 所 示 。 


Iptables 防 火 墙 默认 的 规则 表 、 链 结构 


第 1 条 规则 
第 2 条 规则 


ra 
PREROUTING&E | PREROUTING 链 | 


第 3 条 规则 
el 


| FORW/ARD 链 | 
OUTPUT 链 攻 


图 3.21 不 同 表 的 挂 接点 


当 Linux 协 议 栈 的 数据 处 理 运 行 到 挂 接点 时 ， 它 会 依次 调用 挂 接点 
上 所 有 的 挂钩 画 数 ， 直 到 数据 包 的 处 理 结果 是 明确 地 接受 或 者 拒绝 。 


2) 处 理 规则 
每 个 规则 的 特性 都 分 为 以 下 几 部 分 : 


。 RRA (准备 干什么 事情 ) ， 

。 什 么 挂 接点 (什么 时 候 起 作用 ) ; 

。 匹配 的 参数 是 什么 (针对 什么 样 的 数据 包 ) ; 

。 匹配 后 有 什么 动作 (匹配 后 具体 的 操作 是 什么 ) 。 


表 类 型 和 什么 挂 接点 在 前 面 已 经 介绍 了 ， 现 在 我 们 看 看 匹配 的 参 
数 和 匹配 后 的 动作 。 


(1) 匹配 的 参数 


匹配 的 参数 用 于 对 数据 包 或 者 TCP 数 据 连 接 的 状态 进行 匹配 。 当 
有 多 个 条 件 存在 时 ， 它 们 一 起 起 作用 ， 来 达到 只 针对 某 部 分 数据 进行 
修改 的 目的 。 利 见 的 匹配 参数 有 : 


。 流 入、 流出 的 网 络 接口 
。 来源、 目的 地 址 ; 
协议 类 型 
来 源 、 目 的 端口 。 


(2) 匹配 后 的 动作 


一 旦 有 数据 匹配 上 ， 驶 会 执行 相应 的 动作 。 动 作 类 型 既 可 以 是 标 
准 的 预定 义 的 几 个 动作 ， 也 可 以 是 目 定 义 的 模块 注册 的 动作 ， 或 者 是 
一 个 新 的 规则 链 ， 以 便 更 好 地 组 织 一 组 动作 。 


3) Iptables 命 令 


Iptables 命令 用 于 协助 用 户 维护 各 种 规则 。 我 们 在 使 用 
Kubernetes、Docker 的 过 程 中 ， 通 常 都 会 去 查看 相关 的 Netfilter 配 置 。 
这 里 只 介绍 如 何 查 看 规则 表 ， 详 细 的 介绍 请 参照 Linux 的 Iptables 帮 助 
文档 e 


查看 系统 中 已 有 的 规则 的 方法 如 下 。 


e iptables-save: 按照 命令 的 方式 打印 Iptables 的 内 容 。 


e Iptables-vnL: 以 男 一 种 格式 显示 Netfilter 表 的 内 容 。 


5. 路 由 


Linux 系 统 包含 一 个 完整 的 路 由 功能 。 当 IP 层 在 处 理 数据 发 送 或 者 
转发 的 时 候 ， 会 使 用 路 由 表 来 决定 发 往 哪 里 。 通 向 情况 下 ， 如 采 主 机 
与 目的 主机 直接 相连 ， 那 么 主机 可 以 直接 发 送 IP 报 文 到 目的 主机 ， 这 
个 过 程 比较 简单 。 例 如， 通过 点 对 点 的 链接 或 通过 网 络 共 至 ， 如 有 果 主 
机 与 目的 主机 没有 直接 相连 ， 那 么 主机 会 将 IP 报 文 发 送 给 默认 的 路 由 
顺 ， 然 后 由 路 由 右 来 决定 往 哪 发 送 IP 报 文 。 


路 由 功能 由 IP 层 维护 的 一 张 路 由 表 来 实现 。 当 主机 收 到 数据 报 文 
时 ， 它 用 此 表 来 决策 接 下 来 应 该 做 什么 操作 。 当 从 网 络 侧 接收 到 数据 
报 文 时 ，IP 层 首先 会 检查 报 文 的 IP 地 址 是 否 与 主机 自身 的 地 址 相同 。 
如 栗 数 据 报 文中 的 下 地 址 站 主机 目 身 的 地 址 ， 那 么 报 文 将 被 发 送 到 传 
输 层 相应 的 协议 中 去 。 如 果 报 文中 的 IP 地 址 不 古 主机 目 喘 的 地 址 ， 并 
旦 主机 配置 了 路 由 功能 ， 那 么 报 文 将 被 转发 ， 否 则 ， 报 文 将 被 丢弃 。 


路 由 表 中 的 数据 一 般 钙 以 条 目 形式 存在 的 。 一 个 典型 的 路 由 表 条 
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(1) 目的 下 地 址 : 此 字段 表示 目标 的 了 地址 。 这 个 下地 址 可 以 是 
某 台 主机 的 地 址 ， 也 可 以 是 一 个 网 络 地 址 。 如 果 这 个 条 目 包含 的 是 一 
个 主机 地 址 ， 那 么 它 的 主机 ID 将 被 标记 为 非 零 ， 如 果 这 个 条 目 包含 的 
是 一 个 网 络 地 址 ， 那 么 它 的 主机 ID 将 被 标记 为 零 。 


(2) 下 一 个 路 由 器 的 卫 地 址 : 为 什么 采用 “下 一 个 ”的 说 法 ， 有 是 因 
为 下 一 个 路 由 器 并 不 总 是 最 终 的 目的 路 由 右 ， 它 很 可 能 钙 一 个 中 间 路 


由 器 。 条 目 给 出 下 一 个 路 由 器 的 地 址 用 来 转发 从 相应 接口 接收 到 的 IP 
数据 报 文 。 


(3) 标志 : 这 个 字段 提供 了 男 一 组 重要 信息 ， 例 如 目的 IP 地 址 是 
一 个 主机 地 址 还 是 一 个 网 络 地 址 。 此 外 ， 从 标志 中 可 以 得 知 下 一 个 路 
由 器 是 一 个 真实 路 由 絮 还 是 一 个 直接 相连 的 接口 。 


(4) 网 络 接口 规范 : 为 一 些 数据 报 文 的 网 络 接口 规范 ， 该 规范 将 
与 报 文 一 起 被 转发 。 


在 通过 路 由 表 转 发 时 ， 如 果 任 何 条 目的 第 1 个 字段 完全 匹配 目的 了 
地 址 (主机 ) 或 部 分 匹配 条 目的 IP 地 址 (网络) ， 那 么 它 将 指示 下 一 
个 路 由 器 的 人 Pp 地址 。 这 是 一 个 重要 的 信息 ， 因 为 这 些 信息 直接 告诉 主 
机 (具备 路 由 功能 的 ) 数据 包 应 该 转发 到 哪个 “下 一 个 路 由 器 ”去 。 而 
条 目 中 的 所 有 其 他 字段 将 提供 更 多 的 辅助 信息 来 为 路 由 转发 做 决定 。 


如 果 没 有 找到 一 个 完全 匹配 的 卫 ， 那 么 惑 接着 搜索 相 匹配 的 网 络 
ID。 如 果 找 到 ， 那 么 该 数据 报 文 会 被 转发 到 指定 的 路 由 器 上 。 可 以 看 
出 ， 网 络 上 的 所 有 主机 都 通过 这 个 路 由 表 中 的 单个 (这 个 ) 条 目 进行 


管理 。 


如 果 上 壕 两 个 条 件 都 不 匹配 ， 那 么 该 数据 报 文 将 被 转发 到 一 个 点 
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无 法 被 转发 。 任 何 无 法 投递 的 数据 报 文部 将 产生 一 个 ICMP 主 机 不 可 达 
或 ICMP 网 络 不 可 达 的 错误 ， 并 将 此 错误 返回 给 生成 此 数据 报 文 的 应 用 
程序 。 


1) 路 由 表 的 创建 


Linux 的 路 由 表 至 少 包括 两 个 表 ( 当 启 用 策略 路 由 的 时 候 ， 还 会 
其 他 表 ) : 一 个 是 LOCAL ， 另 一 个 是 MAIN。 在 LOCAL 表 中 会 包含 所 
有 的 本 地 设备 地 址 。LOCAL 路 由 表 是 在 配置 网 络 设备 地 址 时 自动 创建 
的 。LOCAL 表 用 于 供 Linux 协 议 栈 识别 本 地 地 址 ， 以 及 进行 本 地 各 个 
不 同 网 络 接口 之 间 的 数据 转发 。 


可 以 通过 下 面 的 命令 查看 LOCAL 表 的 内 容 : 


# ip route show table local type local 
10.1.1.0 dev flannelO proto kernel scope host src 
10.1.1.0 
127.0.0.0/8 dev lo proto kernel scope host src 
127.0.0.1 
127.0.0.1 dev lo proto kernel scope host src 
127.0.0.1 
172.17.42.1 dev docker proto kernel scope host src 
172.17.42.1 
192.168.1.128 dev enoi16777736 proto kernel scope 
host src 192.168.1.128 


MAIN 表 用 于 各 类 网 络 IP 地 址 的 转发 。 它 的 建立 既 可 以 使 用 静态 
配置 生成 ， 也 可 以 使 用 动态 路 由 发 现 协 议 生 成 。 动 态 路 由 发 现 协 议 一 
般 使 用 组 播 功 能 来 通过 发 送 路 由 发 现 数据 ， 动 态 地 交换 和 获取 网 络 的 
路 由 信息 ， 并 更 新 到 路 由 表 中 。 


Linux 下 文 持 路 由 发 现 协议 的 开源 软件 有 许多 ， 常 用 的 有 Quagga、 
Zebra 等 。 第 4 章 会 介绍 使 用 Quagga 动 态 容 器 路 由 发 现 的 机 制 来 实现 
Kubernetes 的 网 络 组 网 。 


2) 路 由 表 的 查看 
我 们 可 以 使 用 ip route list 命 令 查 看 当前 的 路 由 表 。 


# ip route list 
192.168.6.0/24 dev eno16777736 proto kernel scope 


link src 192.168.6.140 metric 1 


在 上 面 的 例子 代码 中 ， 只 个子 网 的 路 由 ， 源 地 址 是 
192.168.6.140 (本 机 ) ， 目 标 地 址 是 192.168.6.0/24 网 段 的 数据 ， 都 将 
通过 eth0 接 口 设 备 发 送出 去 。 


Netstat-rn 是 另 一 个 查看 路 由 表 的 工具 : 


# netstat -rn 


Kernel IP routing table 


Destination Gateway Genmask 
Flags MSS Window irtt Iface 
0.0.0.0 192.168.6.2 0.0.0.0 UG 
0 0 0 etho 
192 .168.6.0 0.0.0.0 255.255.255.0 U 


0 0 © etho 


在 它 显 示 的 信息 中 ， 如 果 标 志 是 U， 则 说 明 是 可 达 路 由 ;如果 标 
志和 是 G， 则 说 明 这 个 网 络 接口 连接 的 是 网 关 ， 人 否则 说 明 走 直 连 主机 。 


3.7.3 ”Docker 的 网 络 实现 


标准 的 Docker 支 持 以 下 4 类 网 络 模式 。 


。 host 模 式 ， 使 用 --net=host 指 定 。 

。 container z: 使 用 --net=container: NAME or ID 指定 。 
。 none 模 式 : 使 用 --net=none 指 定 。 

。bridge 模 式 : 使 用 --net=bridge 指 定 ， 为 默认 设置 。 


在 Kubernetes 管 理 模式 下 ， 通 种 只 会 使 用 bridge 模 式 ， 所 以 本 万 只 
介绍 bridge 模 式 下 Docker 是 如 何 支 持 网 络 的 。 


在 bridge 模 式 下 ，Docker Daemon 第 1 次 启动 时 会 创建 一 个 虚拟 的 
网 桥 ， 上 默认 的 名 子 是 docker0， 然 后 按照 RPC1918 的 模型 ， 在 私有 网 络 
空间 中 给 这 个 网 桥 分 配 一 个 子 网 。 针 对 由 Docker 创 建 出 来 的 每 一 个 容 
器 ， 都 会 创建 一 个 虚拟 的 以 太 网 设备 〈Veth 设 备 对 ) ， 其 中 一 端 关 联 
到 网 桥 上 ， 男 一 端 使 用 Linux 的 网 络 命 名 空间 技术 ， 映 射 到 容 强 内 的 
eth0 设 备 ， 然 后 从 网 桥 的 地 址 段 内 给 eth0 接 口 分 配 一 个 IP 地 址 。 


如 图 3.22 所 示 就 是 Docker 的 默认 桥接 网 络 模 型 。 


图 3.22 ”默认 的 Docker 网 络 桥接 模型 


其 中 ip1 是 网 桥 的 卫 地 址 ，Docker Daemon 会 在 儿 个 备 选 地 址 段 里 
给 "e 通常 是 172 开 头 的 一 个 地 址 。 这 个 地 址 和 主机 的 IP 地 址 是 
不 重合 的 。ip2 是 Docker 在 局 动容 强 的 上 时候， 在 这 个 地 址 段 随机 选择 的 
一 个 没有 使 用 的 IP 地 址 ，Docker 占 用 它 并 分 配给 了 被 启动 的 容器 。 相 


应 的 MAC 地 址 也 根据 这 个 IP 地 址 ， 在 02: 42: ac: 11: 00: 00/102: 
42: ac: 11: ff: 任 的 范围 内 生成 ， 这 样 做 可 以 确保 不 会 有 ARP 的 冲 
突 o 
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在 一 般 情况 下 ，ip1、ip2 和 ip3 是 不 同 的 IP 段 ， 所 以 在 默认 不 做 任 
何 特殊 配置 的 情况 下 ， 在 外 部 是 看 不 到 ip1 和 ip2 的 。 


这 样 做 的 结果 就 十， 同一 台 机 器 内 的 容器 之 间 可 以 相互 通信 。 不 
同 主机 上 的 容器 不 能 够 相互 通信 。 实 际 上 它们 甚至 有 可 能 会 在 相同 的 
网 络 地 址 范围 内 (不 同 的 主机 上 的 docker0 的 地 址 段 可 能 是 一 样 的 。 


为 了 让 它们 跨 市 点 互相 通信 ， 丈 必须 在 主机 的 地 址 上 分 配 并 口 ， 
然后 通过 这 个 端口 路 由 或 代理 到 容器 上 。 这 种 做 法 显然 意味 着 一 定 要 
在 容器 之 间 小 心 齐 慎 地 协调 好 端口 的 分 配 ， 或 者 使 用 动态 端口 的 分 配 
技术 。 在 不 同 应 用 之 间 协 调 好 端口 分 配 是 十 分 困难 的 事情 ， 等 别 征 集 
群 水 平 扩展 的 时 候 。 而 动态 的 端口 分 配 也 会 带 来 高 度 复杂 性 ， 例 如 : 
每 个 应 用 程序 都 只 能 将 端口 看 作 一 个 符号 (因为 是 动态 分 配 的 ， 无 法 
提前 设置 ) 。 而 且 API Server 也 要 在 分 配 完 后 ， 将 动态 端口 插入 到 配置 
的 合适 位 置 。 另 外 ， 服 务 也 必须 能 互相 之 间 找 到 对 方 等 。 这 些 都 是 
Docker 的 网 络 模 型 在 跨 主 机 访问 时 面临 的 问题 。 


1) 查看 Docker 启 动 后 的 系统 情况 


我 们 已 经 知道 ，Docker 网 络 在 bridge 模 式 下 Docker Daemon 启 动 时 
创建 docker0 网 桥 ， 并 在 网 桥 使 用 的 网 段 为 容器 分 配 卫 。 让 我 们 看 看 实 
际 的 操作 。 


在 刚刚 启动 DockerDaemon 并 且 还 没有 局 动 任 何 容 喜 的 时 候 ， 网 络 
协议 栈 的 配置 情况 如 下 : 


# systemctl start docker 
# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: enoi16777736: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 
1500 qdisc pfifo fast state UP qlen 1000 
link/ether 00:0c:29:14:3d:80 brd ff:ff:ff:ff:ff:ff 
inet 192.168.1.133/24 brd 192.168.1.255 scope 
global enoi16777736 
valid lft forever preferred lft forever 
inet6 fe80::20c:29ff:fe14:3d480/64 scope link 
valid lft forever preferred lft forever 
3: docker0O: <NO-CARRIER, BROADCAST,MULTICAST,UP> mtu 
1500 qdisc noqueue state DOWN 
link/ether 02:42:6e:af:0e:c3 brd ff:ff:ff:ff:ff:ff 
inet 172.17.42.1/24 scope global dockerO 


valid lft forever preferred lft forever 


# iptables-save 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
17:11:04 2015 
*nat 
:PREROUTING ACCEPT [7:878] 
:INPUT ACCEPT [7:878] 
:OUTPUT ACCEPT [3:536] 
:POSTROUTING ACCEPT [3:536] 
:DOCKER - [0:0] 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type 
LOCAL -j DOCKER 
-A POSTROUTING -s 172.17.0.0/16 ! -o dockerO -j 
MASQUERADE 
COMMIT 
# Completed on Thu Sep 24 17:11:04 2015 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
17:11:04 2015 
*filter 
: INPUT ACCEPT [133:11362] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [37:5000] 
:DOCKER - [0:0] 
-A FORWARD -o dockerO -j DOCKER 
-A FORWARD -o dockerO -m conntrack --ctstate 
RELATED, ESTABLISHED -j ACCEPT 


-A FORWARD -i dockerO ! -o dockerO -j ACCEPT 


-A FORWARD -i dockerO -o dockerO -j ACCEPT 
COMMIT 
# Completed on Thu Sep 24 17:11:04 2015 


可 以 看 到 ，Docker 创 建 了 docker0 网 桥 ， 并 添加 了 Iptables 规 则 。 
docker0 网 桥 和 Iptables 规 则 都 处 于 root 命 名 空间 中 。 通 过 解读 这 些 规 
则 ， 我 们 发 现 ， 在 还 没有 启动 任何 容器 时 ， 如 采 启 动 了 Docker 
Daemon， 那 么 它 融 已 经 做 好 了 通信 的 准备 。 对 这 些 规则 的 说 明 如 下 。 


(1) 在 NAT 表 中 有 3 条 记录 ， 前 两 条 匹配 生效 后 ， 都 会 继续 执行 
DOCKER 链 ， 而 此 时 DOCKER 链 为 空 ， 所 以 前 两 条 只 是 做 了 个 框 染 ， 
并 没有 实际 效果 。 


(2) NAT 表 第 3 条 的 含义 是 ， 若 本 地 发 出 的 数据 包 不 是 发 往 
docker0 的 ， 即 是 发 往 主 机 之 外 的 设备 的 ， 都 需要 进行 动态 地 址 修改 
(MASQUERADE) ， 将 源 地 址 从 容器 的 地 址 (172 段 ) 修改 为 宿主 机 
网 卡 的 IP 地 址 ， 之 后 就 可 以 发 送 给 外 面 的 网 络 了 。 


(3) 在 FILTER 表 中 ， 第 1 条 也 是 一 个 框架 ， 因 为 后 继 的 DOCKER 
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(4) 在 FILTER 表 中 ， 第 3 条 是 说 ，docker0 发 出 的 包 ， 如 果 需 要 
Forward £| JË docker0 的 本 地 下 地 址 的 设备 ， 则 是 允许 的 ， 这 样 ， 
docker0 设 备 的 包 束 可 以 根据 路 由 规则 中 转 到 宿主 机 的 网 卡 设备 ， 从 而 
访问 外 面 的 网 络 。 


(5) FILTER 表 中 ， 第 4 条 是 说 ，docker0 的 包 还 可 以 中 转 给 
docker0 本 身 ， 即 连接 在 docker0 网 桥 上 的 不 同 容 器 之 间 的 通信 也 是 允许 
的 。 


(6) FILTER 表 中 ， 第 2 条 是 说 ， 如 果 接 收 到 的 数据 包 属 于 以 前 已 
经 建立 好 的 连接 ， 那 么 允许 直接 通过 。 这 样 接收 到 的 数据 包 目 然 又 走 
回 docker0， 并 中 转 到 相应 的 容 妖 。 


除了 这 些 Netfilter 的 设置 ，Linux 的 ip_forward 功 能 也 被 Docker 
Daemon} F T: 


# cat /proc/sys/net/ipv4/ip_forward 
1 


另外 ， 我 们 还 可 以 看 到 刚刚 启动 Docker 后 的 Route 表 ， 和 局 动 前 没 
有 什么 不 同 : 


# ip route 
default via 192.168.1.2 dev eno16777736 proto static 
metric 100 
172.17.0.0/16 dev docker proto kernel scope link 
sre 172.17.42.1 
192.168.1.0/24 dev enoi16777736 proto kernel scope 
link src 192.168.1.132 
192.168.1.0/24 dev enoi16777736 proto kernel scope 


link src 192.168.1.132 metric 100 


2 
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刚才 我 们 看 了 Docker 服 务 启动 后 的 网 络 情况 。 现 在 ， 我 们 局 动 一 
个 Registry 容 器 后 (不 使 用 任何 端口 镜像 参数 ) ， 看 一 下 网 络 堆 栈 部 分 
相关 的 变化 : 


docker run --name register -d registry 


# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 


state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid lft forever preferred lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: enoi16777736: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 
1500 qdisc pfifo fast state UP qlen 1000 
link/ether 00:0c:29:c8:12:5f brd ff:ff:ff:ff:ff:ff 


inet 192.168.1.132/24 brd 192.168.1.255 scope 
global eno16777736 
valid lft forever preferred lft forever 
inet6 fe80::20c:29ff:fec8:125f/64 scope link 
valid lft forever preferred lft forever 


3: docker0: <NO-CARRIER, BROADCAST,MULTICAST,UP> mtu 


1500 qdisc noqueue state DOWN 
link/ether 02:42:72:79:b8:88 brd ff: ff: ff: ff: FF: FF 


inet 172.17.42.1/24 scope global dockerO 
valid lft forever preferred lft forever 

inet6 fe80::42:7aff:fe79:b888/64 scope link 
valid lft forever preferred lft forever 


13: veth2dc8bbd: «BROADCAST, MULTICAST, UP, LOWER UP» mtu 


1500 qdisc noqueue master dockerO state UP 
link/ether be:d9:19:42:46:18 brd ff:ff:ff:ff:ff:ff 
inet6 fe80::bcd9:19ff:fe42:4618/64 scope link 


valid lft forever preferred lft forever 


# iptables-save 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
18:21:04 2015 
*nat 
:PREROUTING ACCEPT [14:1730] 
:INPUT ACCEPT [14:1730] 
:OUTPUT ACCEPT [59:4918] 
:POSTROUTING ACCEPT [59:4918] 
:DOCKER - [0:0] 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type 
LOCAL -j DOCKER 
-A POSTROUTING -s 172.17.0.0/16 ! -o dockerO -j 
MASQUERADE 
COMMIT 
# Completed on Thu Sep 24 18:21:04 2015 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
18:21:04 2015 
*filter 
:INPUT ACCEPT [2383:211572] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [2004:242872] 


:DOCKER - [0:0] 
-A FORWARD -o dockerO -j DOCKER 
-A FORWARD -o dockerO -m conntrack --ctstate 

RELATED, ESTABLISHED -j ACCEPT 

-A FORWARD -i dockerO ! -o dockerO -j ACCEPT 

-A FORWARD -i dockerO -o dockerO -j ACCEPT 

COMMIT 

# Completed on Thu Sep 24 18:21:04 2015 


# ip route 
default via 192.168.1.2 dev eno16777736 proto static 
metric 100 
172.17.0.0/16 dev docker proto kernel scope link 
sre 172.17.42.1 
192.168.1.0/24 dev enoi16777736 proto kernel scope 
link sre 192.168.1.132 
192.168.1.0/24 dev eno16777736 proto kernel scope 


link src 192.168.1.132 metric 100 


可 以 看 到 如 下 情况 。 


(1) 答 主 机 器 上 的 Netfilter 和 路 由 表 都 没有 变化 ， 说 明 在 不 进行 
端口 映射 时 ，Docker 的 默认 网 络 是 没有 特殊 处 理 的 。 相 关 的 NAT 和 和 
FILTER 两 个 Netfilter 链 还 是 空 的 。 


(2) 宿主 机 上 的 Veth 对 已 经 建立 ， 并 连接 到 了 容器 内 。 
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我 们 再 次 进入 刚刚 局 动 的 容器 内 ， 看 看 网 络 栈 是 什么 情况 。 容 
内 部 的 IP 地 址 和 路 由 如 下 : 


# docker exec -ti 24981a750a1a bash 
[root@24981a750a1a /]# ip route 
default via 172.17.42.1 dev ethO 
172.17.0.0/16 dev ethO proto kernel scope link src 
172.17.0.10 
[root@24981a750ala /]# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid_lft forever preferred_lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
22: eth0: «BROADCAST,MULTICAST,UP, LOWER UP» mtu 1500 
qdisc noqueue state UP 
link/ether 02:42:ac:11:00:0a brd ff:ff:ff:ff:ff:ff 
inet 172.17.0.10/16 scope global ethO 
valid lft forever preferred lft forever 
inet6 fe80::42:acff:fe11:a/64 scope link 


valid lft forever preferred lft forever 


我 们 可 以 看 到 ， 默 认 集 止 的 回环 设备 lo 已 经 个 局 动 ， 外 面 答 主机 
连接 进来 的 Veth 设 备 也 被 命名 成 了 eth0， 并 且 已 经 配置 了 地 址 


172.17.0.10 ° 


路 由 信息 表 包 含 一 条 到 docker0 的 子 网 路 由 和 一 条 到 docker0 的 默认 
路 由 。 


3) 查看 容 万 局 动 后 的 情况 CE gH m BR) 


下 面 ， 我 们 用 带 端 口 映 射 的 命令 局 动 registry: 
docker run --name register -d -p 1180:5000 registry 


在 启动 后 查看 Iptables 的 变化 。 


# iptables-save 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
18:45:13 2015 
*nat 
:PREROUTING ACCEPT [2:236] 
:INPUT ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
:DOCKER - [0:0] 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type 
LOCAL -j DOCKER 
-A POSTROUTING -s 172.17.0.0/16 ! -o dockerO -j 
MASQUERADE 


-A POSTROUTING -s 172.17.0.19/32 -d 172.17.0.19/32 -p 


tcp -m tcp --dport 5000 -j MASQUERADE 
-A DOCKER ! -i dockerO -p tcp -m tcp --dport 1180 -j 
DNAT --to-destination 172.17.0.19:5000 
COMMIT 
# Completed on Thu Sep 24 18:45:13 2015 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
18:45:13 2015 
*filter 
: INPUT ACCEPT [54:4464] 
: FORWARD ACCEPT [0:0] 
: OUTPUT ACCEPT [41:5576] 
:DOCKER - [0:0] 
-A FORWARD -o dockerO -j DOCKER 
-A FORWARD -o dockerO -m conntrack --ctstate 
RELATED, ESTABLISHED -j ACCEPT 
-A FORWARD -i dockerO ! -o dockerO -j ACCEPT 
-A FORWARD -i dockerO -o dockerO -j ACCEPT 
-A DOCKER -d 172.17.0.19/32 ! -i dockerO -o dockerO -p 
tcp -m tcp --dport 5000 -j ACCEPT 
COMMIT 


# Completed on Thu Sep 24 18:45:13 2015 


从 新 增 的 规则 可 以 看 出 ，Docker 服 务 在 NAT 和 FILTER 两 个 表 内 添 


加 的 两 个 DOCKER 子 链 都 是 给 端口 映射 用 的 。 例 如 本 例 中 我 们 需要 把 
外 面 宿主 机 的 1180 端 口 映 射 到 容器 的 5000 端 口 。 通 过 前 面 的 分 析 我 们 
知道 ， 无 论 是 宿主 机 接收 到 的 还 是 宿主 机 本 地 协议 栈 发 出 的 ， 目 标 地 
址 是 本 地 IP 地 址 的 包 都 会 经 过 NAT 表 中 的 DOCKER 子 链 。Docker 为 每 


一 个 端口 映射 都 在 这 个 链 上 增加 了 到 实际 容器 目标 地 址 和 目标 端口 的 
转换 。 


经 过 这 个 DNAT 的 规则 修改 后 的 卫 包 ， 会 重新 经 过 路 由 模块 的 判 
断 进 行 转发 。 由 于 目标 地 址 和 端口 已 经 是 容器 的 地 址 和 端口 ， 所 以 数 
据 目 然 束 送 到 了 docker0 上 ， 从 而 送 到 对 应 的 容器 内 部 。 


当然 在 Forward 时 ， 也 需要 在 Docker 子 链 中 添加 一 条 规则 ， 如 有 果 目 
标 端口 和 地 址 是 指定 容器 的 数据 ， 则 人 允许 通过 。 


在 Docker 按 照 端 口 映 射 的 方式 局 动容 人 硕 时 ， 主 要 的 不 同 惑 是 上 述 
Iptables 部 分 。 而 容器 内 部 的 路 由 和 网 络 设备 ， 都 和 不 做 端口 映射 时 一 
样 ， 没 有 任何 变化 。 


4) Docker 的 网 络 局 限 


我 们 从 Docker 对 Linux 网 络 协议 栈 的 操作 可 以 看 到 ，Docker 一 开始 
没有 考虑 到 多 主机 互联 的 网 络 解决 方案 。 


Docker 一 直 以 来 的 理念 都 是 “人 简单 为 美 >， 几 乎 所 有 党 试 Docker 的 
人 ， 都 被 它 “ 用 法 简单 ， 功 能 强大 ”的 特性 所 吸引 ， 这 也 是 Docker 迅 速 
走红 的 一 个 原因 。 


我 们 都 知道 ， 虚 拟 化 技术 中 最 为 复杂 的 部 分 就 是 虚拟 化 网 络 技 
术 ， 即 使 是 单纯 的 物理 网 络 部 分 ， 也 是 一 个 门槛 很 高 的 技能 领域 ， 通 
常 只 被 少数 网 络 工程 师 所 掌握 ， 所 以 我 们 可 以 理解 ， 结 合 了 物理 网 络 
的 虚拟 网 络 技术 会 有 多 难 了 。 在 Docker 之 前 ， 所 有 接触 过 OpenStack 的 
人 的 心里 都 有 一 个 难以 释怀 的 阴影 ， 那 就 是 它 的 网 络 问题 ， 于 是 ， 
Docker 明 智 地 避 开 这 个 “ 雷 区 ”， 让 其 他 专业 人 员 去 用 现 有 的 虚拟 化 网 


络 技术 解决 Docker 主 机 的 互联 问题 ， 以 免 让 用 户 觉得 Docker 太 难 了 ， 
从 而 放弃 学 习 和 使 用 Docker 。 


Docker 成 名 以 后 ， 重 新 开始 重视 网 络 解决 方案 ， 收 购 了 一 家 
Docker 网 络 解决 方案 公司 Socketplane， 原 因 在 于 这 家 公司 的 产品 
广 受 好 评 ， 但 有 趣 的 是 Socketplane 的 方案 束 是 以 Open vSwitch 为 核心 
的 ， 其 还 为 Open vSwitch 提 供 了 Docker 镜 像 ， 以 方便 部 署 程序 。 之 
后 ，Docker 开 局 了 一 个 “ 安 伟 ” 的 虚拟 化 网 络 解决 方案 
如 图 3.23 所 示 是 其 概念 图 。 


Libnetwork, 


A Docker Container ' A Docker Contain er i A Docker Container 


[3.23 Libnetworkt& K] 


这 个 概念 图 没有 了 卫 ， 也 没有 了 路 由 ， 已 经 颠覆 了 我 们 的 网 络 和 党 
识 了 ， 对 于 不 怎么 懂 网 络 的 大 多 数 人 来 说 ， 它 的 确 很 有 诱惑 力 ， 未 来 
是 否 会 对 虚拟 化 网 络 的 模型 产生 深远 冲击 我 们 还 不 得 而 知 ， 但 当前 ， 
它 仅 仅 是 Docker 官 方 的 一 次 “ 演 试 ”。 


针对 目前 Docker 的 网 络 实现 ，Docker 使 用 的 Libnetwork 组 件 只 是 
将 Docker 平 台中 的 网 络 子 系统 模块 化 为 一 个 独立 库 的 简单 尝试 ， 离 成 
PUA SCSI AEBS © 
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中 的 多 主机 网 络 解决 方案 。 


3.7.4 ”Kubernetes 的 网 络 实现 


在 实际 的 业务 场景 中 ， 业 务 组件 之 间 的 天 系 十 分 复杂 ， 特 别 是 微 
服务 概念 的 推进 ， 应 用 部 署 的 粒度 更 加 细小 和 灵活 。 为 了 支持 业务 应 
用 组 件 的 通信 联系 ，Kubernetes 网 络 的 设计 主要 致力 于 解决 以 下 场 


Ebo 
(1) 容器 到 容器 之 间 的 直接 通信 。 
(2) 抽象 的 Pod 到 Pod 之 间 的 通信 。 
(3) Pod 到 Service 之 间 的 通信 。 
(4) 集群 外 部 与 内 部 组 件 之 间 的 通信 。 
其 中 第 3 条 、 第 4 条 我 们 在 之 前 的 章节 里 都 讲述 过 ， 本 节 中 我 们 对 
更 为 基础 的 第 1 条 与 第 2 条 进行 深入 分 析 和 讲解 。 
1. 容 器 到 容器 的 通信 


在 同一 个 Pod 内 的 容器 (Pod 内 的 容器 是 不 会 跨 宿 主机 的 ) 共享 同 
一 个 网 络 命 名 空间 ， 共 享 同一 个 Linux 协 议 栈 。 所 以 对 于 网 络 的 各 类 操 
作 ， 就 和 它们 在 同一 台 机 器 上 一 样 ， 它 们 甚至 可 以 用 localhost 地 址 访 
问 彼此 的 端口 。 


这 人 么 做 的 结 末 是 简单 、 安 全 和 高 效 ， 也 能 减少 将 已 经 存在 的 程序 
从 物理 机 或 者 虚拟 机 移植 到 容器 下 运行 的 难度 。 在 容器 技术 出 来 之 
前 ， 其 实 大 家 早 束 积 索 了 如 何在 一 台 机 器 上 运行 一 组 应 用 程序 的 经 
验 ， 例 如 ， 如 何 让 端口 不 冲突 ， 以 及 如 何 让 客户 端 发 现 它们 等 。 


我 们 来 看 一 下 Kubernetes 是 如 何 利用 Docker 的 网 络 模型 的 。 


图 3.24 中 的 阴影 部 分 就 是 在 Node 上 运行 着 的 一 个 Pod 实 例 。 在 我 们 
的 例子 中 ， 容 器 束 古 图 3.24 中 的 容 右 1 和 容 絮 2。 容 絮 1 和 容 絮 2 共享 了 
一 个 网 络 的 命名 空间 ， 共 享 一 个 命名 空间 的 结 采 就 是 它们 好 像 在 一 台 
机 妖 上 运行 似 的 ， 它 们 打开 的 端口 不 会 有 冲突 ， 可 以 直接 使 用 Linux 的 
本 地 IPC 进 行 通 信 (例如 消息 队列 或 者 管道 ) 。 其 实 这 和 传统 的 一 组 
普通 程序 运行 的 环境 是 完全 一 样 的 ， 传 统 的 程序 不 需要 针对 网 络 做 特 
别 的 修改 惑 可 以 移植 了 。 它 们 之 间 的 互相 访问 只 需要 使 用 localhost 整 
可 以 。 例 如 ， 如 果 容 姻 2 运 行 的 是 MySQL， 那 么 容 絮 1 使 用 localhost: 


一 一 


3306 就 能 直接 访问 这 个 运行 在 容 老 2 上 的 MySQL T ° 
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3.24 Kubernetes 的 Pod 网 络 模型 


2.Pod 之 间 的 通信 


我 们 看 了 同一 个 Pod 内 的 容 帮 之 间 的 通信 和 情况， 再 看 看 Pod 之 间 的 
通信 情况 。 


每 一 个 Pod 都 有 一 个 真实 的 全 局 IP 地 址 ， 同 一 个 Node 内 的 不 同 Pod 
之 间 可 以 直接 采用 对 方 Pod 的 IP 地 址 通信 ， 而 且 不 需要 使 用 其 他 发 现 机 
制 ， 例 如 DNS、Consul 或 者 etcd ° 


Pod 容 器 既 有 可 能 在 同一 个 Node 上 运行 ， 也 有 可 能 在 不 同 的 Node 
上 运行 ， 所 以 通信 也 分 为 两 类 : 同一 个 Node 内 的 Pod 之 间 的 通信 和 不 
后 Node 上 有 的 Pod 之 间 的 通信 。 


1) 同一 个 Node 内 的 Pod 之 间 的 通信 
我 们 看 一 下 同一 个 Node 上 的 两 个 Pod 之 间 的 关系 ， 如 图 3.25 所 示 。 


可 以 看 出 ，Pod1 和 Pod2 都 是 通过 Veth 连 接 在 同一 个 docker0 网 桥 上 
的 ， 它 们 的 IP 地 址 IP1、IP2 都 是 从 docker0 的 网 段 上 动态 获取 的 ， 它 们 
和 网 桥 本 身 的 IP3 是 同一 个 网 段 的 。 


另外 ， 在 Pod1、Pod2 的 Linux 协 议 栈 上 ， 默 认 路 由 都 是 docker0 的 
地 址 ， 也 就 是 说 所 有 非 本 地 地 址 的 网 络 数据 ， 都 会 被 默认 发 送 到 
docker0 网 桥 上 ， 由 docker0 网 桥 直 接 中 转 。 


综 上 所 述 ， 由 于 筷 们 都 关联 在 同一 个 docker0 网 桥 上 ， 地 址 段 相 
同 ， 所 以 它们 之 间 是 能 直接 通信 的 。 


Node1 


Pod 1 Pod 2 
容器 1 容器 2 容器 1 容器 2 
共享 网 络 共享 网 络 
空间 - 空间 i 
eo 
uL 
| <> 


Docker0 网 桥 


图 3.25 ”同一 个 Node 内 的 Pod 关 系 
2) 不 同 Node 上 的 Pod 之 间 的 通信 


Pod 的 地 址 是 与 docker0 在 同一 个 网 段 内 的 ， 我 们 知道 docker0 网 段 
与 宿主 机 网 卡 是 两 个 完全 不 同 的 IP 网 段 ， 并 且 不 同 Node 之 间 的 通信 只 


能 通过 笨 主 机 的 物理 网 卡 进行 ， 因 此 要 楚 ee 
Aan ZBI, BLD AAD) 法 通 过 主机 的 这 个 JP 地址 来 进行 寻 址 和 
通信 。 


男 一 方面 ， 这 些 动 态 分 配 晶 藏 在 docker0 之 后 的 所 谓 “ 私 有 ”IP 地 址 
也 是 可 以 找到 的 。Kubernetes 会 记录 所 有 正在 运行 Pod 的 IP 分 配 信 息 
并 将 这 些 信息 保存 在 etcd 中 (作为 Service 的 Endpoint) 。 这 些 私 有 pi 


思 对 于 Pod 到 Pod 的 通信 也 是 十 分 重要 的 ， 因 为 我 们 的 网 络 模型 要 求 
Pod 人 到 Pod 使 用 私有 IP 进 行 通信 。 所 以 首先 要 知道 这 些 IP 是 什么 。 


之 前 提 人 到，Kubemetes 的 网 络 对 Pod 的 地 址 是 平面 的 和 直达 有 的， 所 
以 这 些 Pod 的 卫 规 划 也 很 重要 ， 不 能 有 冲突 。 只 要 没有 神 突 ， 我 们 就 可 
以 想 办 法 在 整个 Kubernetes 的 集群 中 找到 它 。 


绕 上 所 述 ， 要 想 文 持 不 同 Node 上 的 Pod 之 间 的 通信 ， 就 要 达到 两 


SRE: 


(1) 在 整个 Kubernetes 集 群 中 对 Pod 的 IP 分 配 进行 规划 ， 不 能 有 冲 


PS 
F; 


(2) 找到 一 种 办 法 ， 将 Pod 的 人 和 所 在 Node 的 IP 关 联 起 来 ， 通 过 
这 个 关联 让 Pod 可 以 互相 访问 。 


根据 条 件 1 的 要 求 ， 我 们 需要 在 部 署 Kubernetes 的 时 候 ， 对 docker0 
的 IP 地 址 进行 规划 ， 保 证 每 一 个 Node 上 的 docker0 地 址 没有 冲突 。 我 们 
可 以 在 规划 后 手工 配置 到 每 个 Node 上， 或 者 做 一 个 分 配 规则 ， 由 安装 
的 程序 自己 去 分 配 占 用 。 例 如 Kubernetes 的 网 络 增强 开源 软件 Flannel 
残 能 够 管理 资源 池 的 分 配 。 


根据 条 件 2 的 要 求 ，Pod 中 的 数据 在 发 出 时 ， 需 要 有 一 个 机 制 能 够 
知道 对 方 Pod 的 人 P 地 址 挂 在 哪个 具体 的 Node 上 。 也 怠 是 说 移 要 找到 
Node 对 应 答 主 机 的 IP 地 址 ， 将 数据 发 送 到 这 个 和 宿主 机 的 网 卡 上 ， 然 后 
在 宿主 机 上 将 相应 的 数据 转 到 具体 的 docker0 上。 一 旦 数据 到 达 宿 主机 
Node， 则 那个 Node 内 部 的 docker0 便 知道 如 何 将 数据 发 送 到 Pod。 如 图 
3.26 所 示 。 
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图 3.26” 跨 Node 的 Pod 通 信 


在 图 3.26 中 ，IP1 对 应 的 是 Pod1，IP2 对 应 的 是 Pod2。Pod1 在 访问 
Pod2 时 ， 首 先 要 将 数据 从 源 Node 的 eth0 发 送出 去 ， 找 到 并 到 达 Node2 
的 eth0。 也 就 是 说 先 要 从 IP3 到 IP4， 之 后 才 是 IP4 到 IP2 的 递送 。 


在 谷歌 的 GCE 环 境 下 ，Pod 的 IP 管 理 (类 似 docker0) ^ ACRE 
们 之 间 的 路 由 打通 都 是 由 GCE 完 成 的 。Kubernetes 作 为 主要 在 GCE 上 
面 运 行 的 框架 ， 它 的 设计 是 假设 故 层 已 经 具备 这 些 条 件 ， 所 以 它 分 配 
完 地 址 并 将 地 址 记录 下 来 束 完 成 了 它 的 工作 。 在 实际 的 GCE 环 境 中 ， 
GCE 的 网 络 组件 会 恋 取 这 些 信息 ， 实 现 具体 的 网 络 打 通 。 


而 在 实际 的 生产 中 ， 因 为 安全 、 费 用 、 合 规 等 种 种 原因 ， 
Kubernetes 的 客户 不 可 能 全 部 使 用 谷歌 的 GCE 环 境 ， 所 以 在 实际 的 私 


有 云 环 境 中 ， 除 了 部 署 Kubemetes 和 Docker， 还 需要 额外 的 网 络 配 置 ， 
甚至 通过 一 些 软 件 来 实现 Kubernetes 对 网 络 的 要 求 。 做 到 这 些 后 ，Pod 
和 Pod 之 间 才 能 无 差别 地 透明 通信 。 


为 了 达到 这 个 目的 ， 开 源 界 有 不 少 应 用 来 增强 Kubernetes、Docker 
的 网 络 ， 在 后 面 的 章节 里 会 介绍 几 个 常用 的 组 件 和 它们 的 组 网 原理 。 


3.75 ”开源 的 网 络 组 件 


Kubemetes 的 网 络 模型 假定 了 所 有 Pod 都 在 一 个 可 以 直接 连通 的 局 
平 的 网 络 空间 中 。 这 在 GCE 里 面 是 现成 的 网 络 模 型 ，Kubernetes 假 定 
这 个 网 络 已 经 存在 。 而 在 私有 云 里 搭建 Kubernetes 集 群 ， 束 不 能 假定 
这 种 网 络 已 经 存在 了 。 我 们 需要 目 己 实现 这 个 网 络 假设 ， 将 不 同 节 点 
上 的 Docker 容 名 之 间 的 互相 访问 先 打通 ， 然 后 运行 Kubernetes ° 


目前 已 经 有 多 个 开源 组 件 支 持 这 个 网 络 模 型 。 这 里 介绍 几 个 常见 
的 模型 ， 分 别 是 Flannel、Open vSwitch 及 直接 路 由 的 方式 。 


1.Flannel 


Flannel 之 所 以 可 以 搭建 Kubernetes 依 赖 的 底层 网 络 ， 是 因为 它 能 
实现 以 下 两 点 。 


(1) 它 能 协助 Kubernetes， 给 每 一 个 Node 上 的 Docker 容 器 分 配 互 
相 不 冲突 的 IP 地 址 。 
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(2) © BRE EXE 
通过 这 个 覆盖 网 络 ， 将 数据 包 原 封 不 动 地 传递 


(OverlayNetwork) , 
到 目标 容 妖 内 。 


通过 图 3.27 来 看 看 Flannel 是 如 何 实 现 这 两 点 的 。 


可 以 看 到 ，Flannel 首 先 创建 了 一 个 名 为 人 annel0 的 网 桥 ， 而 且 这 个 
网 桥 的 一 端 连接 docker0 网 桥 ， 另 一 端 连 接 一 个 叫 作 flanneld 的 服务 进 
程 。 


flanneld 进 程 并 不 答 单 ， 它 首先 上 连 etcd， 利 用 etcd 来 管理 可 分 配 
的 IP 地 址 段 资源 ， 同 时 监控 etcd 中 每 个 Pod 的 实际 地 址 ， 并 在 内 存 中 建 
并 了 一 个 Pod 市 点 路 由 表 ; 然后 下 连 docker0 和 物理 网 络 ， 使 用 内 存 中 
的 Pod 广 点 路 由 表 ， 将 docker0 发 给 它 的 数据 包 包 装 起 来 ， 利 用 物理 网 
络 的 连接 将 数据 包 投递 到 目标 flanneld 上， 从 而 完成 Pod 到 Pod 之 间 的 直 
接 的 地 址 通信 。 


Flannel 之 间 的 底层 通信 协议 的 可 选 余 地 很 多 ， 有 UDP、VxLan ^ 
AWS VPC 等 多 种 方式 ， 只 要 能 通 到 对 端的 Flannel 束 可 以 了 。 源 
flanneld 加 包 ， 目 标 flanneld 解 包 ， 最 终 docker0 看 到 的 葡 是 原始 的 数 
据 ， 非 常 透 明 ， 根 本 感觉 不 到 中 间 Flannel 的 存在 。 和 党 用 的 是 UDP 。 


3.27 Flannel 架 构 


我 们 看 一 下 Flannel 是 如 何 做 到 让 为 不 同 Node 上 的 Pod 分 配 的 IP 不 
产生 冲突 的 。 其 实 想 到 Flannel 使 用 了 集中 的 etcd 存 储 就 很 容易 理解 
了 。 它 每 次 分 配 的 地 址 段 都 在 同一 个 公共 区 域 获 取 ， 这 样 大 家 自然 能 
够 互相 协调 ， 不 产生 冲突 了 。 而 且 在 Flannel 分 配 好 地 址 段 后 ， 后 面 的 
事情 是 由 Docker 完 成 的 ，Flannel 通 过 修改 Docker 的 启动 参数 将 分 配给 
它 的 地 址 段 传 递 进去 。 


--bip-172.17.18.1/24 


通过 这 些 操 作 ，Flannel 就 控制 了 每 个 Node 上 的 docker0 地 址 段 的 地 
址 ， 也 就 保障 了 所 有 Pod 的 IP 地 址 在 同一 个 水 平 网 络 中 且 不 产生 冲突 
Y o 


Flannel5z 3830, S7 3l f Xf Kubernetes H Axi, BEES ATE 
个 网 络 组 件 ， 在 网 络 通信 时 需要 转 到 flannel0 网 络 接 口 ， 再 转 到 用 户 态 
的 flanneld 程 序 ， 到 对 端 后 还 需要 走 这 个 过 程 的 反 过 程 ， 所 以 也 会 引入 
一 些 网 络 的 时 延 损 耗 。 


另外 ，EFElannel 模 型 默认 使 用 了 UDP 作为 底层 传输 协议 ，UDP 本 身 
征 非 可 靠 协议 ， 虽 然 两 端的 TCP 实 现 了 可 人 靠 传输 ， 但 在 大 流量 、 高 ; 
发 应 用 场景 下 还 需要 反复 测试 ， 确 保 没 有 问题 。 


2.Open VSwitch 


在 了 解 了 Flannel 后 ， 我 们 再 看 看 Open vSwitch 是 怎么 解决 上 壕 两 
个 问题 的 。 


Open vSwitch 是 一 个 开源 的 虚拟 交换 机 软件 ， 有 点 儿 像 Linux 中 的 
bridge， 但 是 功能 要 复杂 得 多 。Open vSwitch 的 网 桥 可 以 直接 建立 多 种 
通信 通道 (隧道) ， 例 如 Open vSwitch with GRE/VxLAN。 这 些 通道 的 
建立 可 以 很 容易 地 通过 OVS 的 配置 命令 实现 。 在 Kubernetes、Docker 场 
景 下 ， 我 们 主要 是 建立 L3 到 L3 的 隧道 。 举 一 个 例子 来 看 看 Open 
vSwitch with GRE/VxLAN 的 网 络 架 构 ， 如 图 3.28 所 示 。 


docker131 192.168.18.131 docker128 192.168 18.128 


13.28 OVS with GRE 原 理 图 


首先 ， 为 了 避免 Docker 创 建 的 docker0 地 址 产生 冲突 (因为 Docker 
Daemon 启 动 且 给 docker0 选 择 子 网 地 址 时 只 有 几 个 备 选 列表 ， 很 容易 
FEWR) ， 我 们 可 以 将 docker0 网 桥 删除 ， 手 动 建立 一 个 Linux 网 
桥 ， 然 后 手动 给 这 个 网 桥 配 置 IP 地 址 范围 。 


其 次 ， 建 立 Open vSwitch 的 网 桥 ovs， 然 后 使 用 ovs-vsctl 命 令 给 ovs 
网 桥 增加 gre 端 口 ， 添 加 gre 端 口 时 要 将 目标 连接 的 NodeIP 地 址 设置 为 
对 端的 耳 地 址 。 对 每 一 个 对 端 耳 地址 都 需要 这 么 操作 (对 于 大 型 集群 
网 络 ， 这 可 是 个 体力 活 ， 要 做 自动 化 脚本 来 完成 ) 


最 后 将 ovs 的 网 桥 作 为 网 络 接口 ， 加 入 Docker 的 网 桥 上 (docker0 
或 者 自己 手工 建立 的 新 网 桥 ) 


重启 ovs 网 桥 和 Docker 的 网 桥 ， 并 添加 一 个 Docker 的 地 址 段 到 
Docker 网 桥 的 路 由 规则 项 ， 就 可 以 将 两 个 容器 的 网 络 连 接 起 来 了 。 


1) 网 络 通信 过 程 


当 容 器 内 的 应 用 访问 男 一 个 容器 的 地 址 时 ， 数 据 包 会 通过 容器 内 
的 默认 路 由 发 送 给 docker0 网 桥 。ovs 的 网 桥 是 作为 docker0 网 桥 的 端口 
存在 的 ， 它 会 将 数据 发 送 给 ovs 网 桥 。ovs 网 络 已 经 通过 配置 建立 了 和 
其 他 ovs 网 桥 的 GRE/VxLAN 隧 道 ， 目 然 能 将 数据 送 达 对 端的 Node， 并 
送 往 docker0 及 Pod。 


通过 新 增 的 路 由 项 ， 使 得 Node 节 点 本 里 的 应 用 的 数据 也 路 由 到 
docker0 网 桥 上 ， 和 刚才 的 通信 过 程 一 样 ， 目 然 也 可 以 访问 其 他 Node 上 
的 Pod ° 


2) OVS with GRE/VxLAN 组 网 方式 的 特点 


OVS 的 优势 是 ， 作 为 开源 虚拟 交换 机 软件 ， 它 相对 比较 成 熟 和 稳 
定 ， 而 且 支 持 各 类 网 络 隧 道 协 议 ， 经 过 了 OpenStack 等 项 目的 考验 。 


男 一 方面 ， 在 前 面 介绍 Flannel 的 时 候 可 知 Flannel 除 了 支持 建立 履 
盖 网 络 (Overlay Network) ， 保 证 Pod 到 Pod 的 无 缝 通信， 还 和 
Kubernetes、Docker 架 构 体 系 结合 紧密 。Flannel 能 够 感知 Kubernetes 的 
Service ， 动 态 维护 目 己 的 路 由 表 ， 还 通过 etcd 来 协助 Docker 对 整个 
Kubernetes 集 群 中 docker0 的 子 网 地 址 分 配 。 而 我 们 在 使 用 OVS 的 时 
候 ， 很 多 事情 瓯 需要 手工 完成 了 。 


无 论 是 OVS 还 是 Flannel， 通 过 禾 盖 网 络 提 供 的 Pod 到 Pod 通 信和 都 会 
引入 一 些 额 外 的 通信 开销 ， 如 果 是 对 网 络 依赖 特别 重 的 应 用 ， 则 需要 


评估 对 业务 的 影响 。 


3. 直 接 路 由 


我 们 知道 ，docker0 网 桥 上 的 IP 地 址 在 Node 网 络 上 是 看 不 到 的 。 从 
一 个 Node 到 一 个 Node 内 的 docker0 是 不 通 的 。 因 为 它 不 知道 某 个 IP 地 址 
在 哪里 。 如 果 能 够 让 这 些 机 器 知道 对 端 docker0 地 址 在 哪里 ， 束 可 以 让 
这 些 docker0 互 相通 信 了 。 这 样 所 有 Node 上 运行 的 Pod 就 可 以 互相 通信 
Te 


我 们 可 以 通过 部 署 MultiLayer Switch (MLS) 来 实现 这 一 点 ， 在 
MLS 中 配置 每 个 docker0 子 网 地 址 到 Node 地 址 的 路 由 项 ， 通 过 MLS 将 
docker0 的 卫 寻 址 定 同 到 对 应 的 Node 节 点 上 。 


另外 ， 我 们 还 可 以 将 这 些 docker0 和 Node 的 匹配 关系 配置 在 Linux 
操作 系统 的 路 由 项 中 ， 这 样 通信 发 起 的 Node 能 够 根据 这 些 路 由 信息 直 
接 找 到 目标 Pod 所 在 的 Node， 将 数据 传输 过 去 。 如 图 3.29 所 示 。 
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图 3.29 直接 路 由 Pod 到 Pod 通 信 
我 们 在 每 个 Node 的 路 由 表 中 增加 对 方 所 有 docker0 的 路 由 项 。 


例如 Pod1 所 在 docker0 网 桥 的 卫 子 网 是 10.1.10.0，Node 的 地 址 为 
192.168.1.128; 而 Pod2 所 在 docker0 网 桥 的 卫 子 网 是 10.1.20.0，Node 的 
地 址 为 192.168.1.129。 


在 Nodel 上 用 route add 命 令 增 加 一 条 到 Node2 上 docker0 的 静态 路 由 
规则 : 


route add -net 10.1.20.0 netmask 255.255.255.0 gw 
192.168.1.129 


同样 ， 在 Node2 上 增加 一 条 到 Nodel 上 docker0 的 静态 路 由 规则 : 


route add -net 10.1.10.0 netmask 255.255.255.0 gw 


192.168.1.128 


这 样 两 个 Node 之 间 的 Pod 束 可 以 互相 通信 了 ， 因 为 它们 发 出 的 数 
据 包 经 过 本 地 Linux 的 路 由 规则 ， 能 将 数据 送 到 对 端的 Node 。 


在 大 规模 集群 中 ， 在 每 个 Node 上 都 需要 配置 到 其 他 docker0/Node 
的 路 由 项 ， 会 市 来 很 大 的 工作 量 ;， 并 且 在 新 增 机 器 时 ， 对 所 有 Node 都 
需要 修改 配置 ; 重 局 机 恬 时 ， 如 果 docker0 的 地 址 有 变化 ， 则 也 需要 修 
改 所 有 Node 的 配置 ， 这 显然 是 非常 复杂 的 。 


为 了 管理 这 些 动态 变化 的 docker0 地 址 ， 动 态 地 让 其 他 Node 都 感知 
到 它 ， 还 可 以 使 用 动态 路 由 发 现 协议 来 同步 这 些 变 化 。 运 行动 态 路 由 
发 现 协议 代理 的 Node， 会 将 本 机 LOCAL 路 由 表 的 耳 地址 通过 组 播 协 议 
发 布 出 去 ， 同 时 监听 其 他 Node 的 组 播 包 。 通 过 这 样 的 信息 交换 ，Node 
上 的 路 由 规则 都 能 够 相互 学 习 到 。 当 然 ， 路 由 发 现 协议 本 喘 还 是 很 复 
杂 的 ， 感 兴趣 的 话 你 可 以 查阅 相关 的 规范 。 在 实现 这 些 动 态 路 由 发 现 
协议 的 开源 软件 中 ， 常 用 的 有 Quagga、Zebra 等 。 下 面 简 单 介 绍 直接 路 
由 的 操作 过 程 。 


(1) 首先 手工 分 配 Docker bridge 的 地 址 ， 保 证 它们 在 不 同 的 网 段 
EDES ° ENRE H Docker Daemon 目 动 创建 的 docker0 (因为 
我 们 不 需要 它 的 自动 管理 功能 ， 而 是 单独 建立 一 个 bridge， 给 它 配 
置 规划 好 的 IP 地 址 ， 然 后 使 用 --bridge=XX 来 指定 网 桥 。 


(2) 然后 在 每 一 个 节点 上 运行 Quagga。 


完成 这 些 操 作 后 ， 我 们 很 快 瓯 能 得 到 一 个 Pod 和 Pod 直 接 互 相 访问 
的 环境 了 “。 由 于 路 由 发 现 能 够 被 网 络 上 的 所 有 设备 接收 ， 所 以 如 有 果 网 
络 上 的 路 由 器 也 能 打开 RIP 协 议 选 项 ， 则 能 够 学 习 到 这 些 路 由 信息 。 
通过 这 些 路 由 器 ， 我 们 甚至 可 以 在 非 Node 节 点 上 使 用 Pod 的 卫 地 址 直 
接 访问 Node 上 的 Pod。 


当然 ， 聪 明 的 你 还 会 有 新 的 疑问 ， 这 样 做 的 话 ， 由 于 每 一 个 Pod 
的 地 址 都 会 被 路 由 发 现 协议 广播 出 去 ， 会 不 会 存在 路 由 表 过 大 的 情 
况 ? 实际 上 ， 路 由 表 通 单 都 会 有 高 速 缓存 ， 碍 找 速度 会 很 快 ， 不 会 对 
性 能 产生 太 大 的 影响 。 当然 ， 如 果 你 的 集群 容量 在 数 千 台 Node 以 上 ， 
则 仍然 需要 测试 和 评估 路 由 表 的 效率 问题 。 


3.7.6 ”网 络 实战 


Docker 给 我 们 带 来 了 不 同 的 网 络 模式 ， 而 Kubernetes 也 以 一 种 不 同 
的 方式 来 解决 这 些 网 络 模式 的 挑战 ， 但 是 其 方式 有 些 不 太 好 理解 ， 特 
别 是 对 于 刚 开 始 接触 Kubernetes 的 网 络 的 开发 者 。 我 们 在 前 面 学 习 了 
Kubernetes、Docker 的 理论 ， 本 市 将 通过 一 个 完整 的 实验 ， 从 部 署 一 个 
Pod 开 始 ， 一 步 一 步 地 部 署 那 些 Kubernetes 的 组 件 ， 来 剖析 Kubernetes 
在 网 络 层 是 如 何 实现 及 如 何 工 作 的 。 


这 里 使 用 虚拟 机 来 完成 实验 。 如 果 你 要 部 署 在 物理 机 器 上 ， 或 者 
部 署 在 云 服 务 商 的 环境 下 ， 则 涉及 的 网 络 模型 很 可 能 稍微 有 所 不 同 。 
不 过 ， 从 网 络 角度 来 看 ，Kubernetes 的 机 制 是 类 似 且 一 致 的 。 


好 了 ， 来 看 看 我 们 的 实验 环境 ， 如 图 3.30 所 示 。 
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192.168.1.130 


Node3 
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图 3.30 ”实验 环境 


Kubernetes 的 网 络 模型 要 求 每 一 个 Node 上 的 容器 都 可 以 相互 访 
问 。 


默认 的 Docker 的 网 络 模型 提供 了 一 个 下 地 址 段 是 172.17.0.0/16 的 
docker0 网 桥 。 每 一 个 容器 都 会 在 这 个 子 网 内 获得 耳 地 址 ， 并 且 将 
docker0 网 桥 的 IP 地 址 (172.17.42.1) 作为 其 默认 网 关 。 需 要 注意 的 是 
Docker 答 主机 外 面 的 网 络 不 需要 知道 任何 关于 这 个 172.17.0.0/16 的 信息 
或 者 知道 如 何 连接 到 它 内 部 ， 因 为 Docker 的 宿主 机 针对 容器 发 出 的 数 
据 ， 在 物理 网 卡 地 址 后 面 都 做 了 IP 伪 装 MASQUERADE (fa & 
NAT) 。 也 就 是 说 ， 在 网 络 上 看 到 的 任何 容器 数据 流 都 来 源 于 那 台 
Docker 六 点 的 物理 IP 地 址 。 这 里 所 说 的 网 络 都 是 指 连接 这 些 主机 的 物 
理 网 络 。 


这 个 模型 便于 使 用 ， 但 是 并 不 完美 ， 需 要 依赖 端口 映射 的 机 制 。 


在 Kubernetes 的 网 络 模型 中 ， 每 台 主 机 上 的 docker0 网 桥 都 是 可 以 
被 路 由 到 的 。 也 残 是 说 ， 在 部 署 了 一 个 Pod 的 时 候 ， 在 同一 个 集群 
内 ， 那 台 主 机 的 外 面 可 以 直接 访问 到 那个 pod， 并 不 需要 在 那 台 物 理 
主机 上 做 端口 映射 。 综 上 所 述 ， 你 可 以 在 网 络 层 将 Kubernetes 的 节点 
看 作 一 个 路 由 器 。 如 果 我 们 将 实验 环境 改 画 成 一 个 网 络 图 ， 那 么 它 看 
起 来 如 图 3.31 所 示 。 


docker0 | dockerO 
route 10.1.20.1 192.168.1.130 10.1,10.1. | —10:1.20.1. .. 
route 10.1.30.1 192.168.1.131 1 | 
192.168.1.130 
route 10.1.10.1 192.168.1.129 
route 10.1.20.1 192.168.1.130 
Kube master 


192.168.1.129 192.168.1.131 
| dockerO | 
20:20:20 ey 


route 10.1.10.1 192.168.1.129 
route 10.1.30.1 192.168.1.131 


图 3.31 ”实验 环境 网 络 图 


为 了 支持 Kubernetes 网 络 模型 ， 我 们 采取 了 直接 路 由 的 方式 来 实 
现 ， 在 每 个 Node 上 配置 相应 的 静态 路 由 项 ， 例 如 在 192.168.1.129 这 个 
Node 上 我 们 配置 了 两 个 路 由 项 : 


# route add -net 10.1.20.0 netmask 255.255.255.0 gw 
192.168.130 


# route add -net 10.1.30.0 netmask 255.255.255.0 gw 
192.168.131 


这 意味 着 ， 每 一 个 新 部 署 的 容器 都 将 使 用 这 个 Node (docker0 的 网 
桥 IP) 作为 它 的 默认 网 关 。 而 这 些 Node 节 点 (类 似 路 由 器 ) 都 有 其 他 
docker0 的 路 由 信息 ， 这 样 它 们 束 能 够 相互 连通 了 。 


接 下 来 通过 一 些 实际 的 案例 ， 来 看 看 Kubernetes 在 不 同 的 场景 下 
其 网 络 部 分 到 瓜 做 了 什么 事情 。 


第 1 步 : 部 署 一 个 RC/Pod 
部 署 的 RC/Pod 描 述 文件 如 下 (frontend-controller.yaml) : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 1 
selector: 
name: frontend 
template: 
metadata: 
labels: 
name: frontend 
spec: 
containers: 


- name: php-redis 


image: kubeguide/guestbook-php-frontend 
env: 
- name: GET_HOSTS_FROM 
value: env 
ports: 
- containerPort: 80 


hostPort: 80 


为 了 便于 观察 ， 我 们 假定 在 一 个 空 的 Kubernetes 集 群 上 运行 ， 提 
前 清理 了 所 有 Replication Controller、Pod 和 其 他 Service: 


# kubectl get rc 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS 
# 
# kubectl get services 
NAME LABELS 
SELECTOR  IP(S) PORT(S) 
kubernetes component=apiserver, provider=kubernetes 
<none>20.1.0.1  443/TCP 
# 
# kubectl get pods 


NAME READY STATUS RESTARTS AGE 


让 我 们 检查 一 下 此 时 某 个 Node 上 的 网 络 接口 都 有 哪些 。Nodel 的 


状态 是 : 


# ifconfig 
dockerO: flags=4099<UP, BROADCAST, RUNNING, MULTICAST> 
mtu 1500 
inet 10.1.10.1 netmask 255.255.255.0 
broadcast 10.1.10.255 
inet6 fe80::5484:7aff:fefe:9799  prefixlen 64 
scopeid 0x20«link» 
ether 56:84:7a:fe:97:99 txqueuelen 0 
(Ethernet) 
RX packets 373245 bytes 170175373 (162.2 MiB) 
RX errors © dropped © overruns © frame 0 
TX packets 353569 bytes 353948005 (337.5 MiB) 
TX errors © dropped 0 overruns © carrier 0 


collisions 0 


eno16777736: 
f lags=4163<UP, BROADCAST, RUNNING, MULTICAST> mtu 1500 
inet 192.168.1.129 netmask 255.255.255.0 
broadcast 192.168.1.255 
inet6 fe80::20c:29ff:fe47:6e2c  prefixlen 64 
scopeid 0x20<link> 
ether 00:0c:29:47:6e:2c txqueuelen 1000 
(Ethernet) 
RX packets 326552 bytes 286033393 (272.7 MiB) 
RX errors © dropped © overruns © frame 0 


TX packets 219520 bytes 31014871 (29.5 MiB) 


TX errors © dropped 0 overruns © carrier 0 


collisions 0 


lo: flags=73<UP, LOOPBACK, RUNNING> mtu 65536 
inet 127.0.0.1 netmask 255.0.0.0 
inet6 ::1 prefixlen 128 scopeid 0x10<host> 
loop txqueuelen O (Local Loopback) 
RX packets 24095 bytes 2133648 (2.0 MiB) 
RX errors © dropped © overruns O frame 0 
TX packets 24095 bytes 2133648 (2.0 MiB) 
TX errors © dropped 0 overruns © carrier 0 


collisions 0 


可 以 看 出 ， 有 一 个 docker0 网 桥 和 一 个 本 地 地 址 的 网 络 端口 。 现 在 
部 署 一 下 我 们 在 前 面 准备 的 RC/Pod 配 置 文件 ， 看 看 发 生 了 什么 : 


# kubectl create -f frontend-controller.yaml 
replicationcontrollers/frontend 

# 

# kubectl get pods 


NAME READY STATUS RESTARTS 
AGE NODE 
frontend-4011g 1/1 Running 0 11s 


192.168.1.130 


可 以 看 到 一 些 有 趣 的 事情 。 ibeni CIPUE 了 一 个 主机 


192.168.1.130 (Node2) 来 运行 它 。 另 外 ， 这 个 Pod 还 获得 了 一 个 在 


Node2 的 docker0 网 桥 上 的 IP 地 址 。 我 们 登录 到 Node2 上 看 看 发 生 了 什么 
事情 : 


# docker ps 
CONTAINER ID IMAGE COMMAND CREATED 
STATUS PORTS NAMES 
37b193a4c633 kubeguide/example-guestbook-php- 
redis "/bin/sh -c /run.sh" 32 seconds ago Up 26 
seconds k8s php-redis.6ad3289e frontend- 


n9nim development 813e2dd9-8149-11e5-823b- 
000c2921ba71 af6dd859 


6dib99cff4ae google containers/pause:latest 
"/pause" 35 seconds ago Up 28 seconds 
0.0.0.0:80->80/tcp k8s_POD.855eeb3d_frontend- 


At52y_development_813e3870-8149-11e5-823b- 
000c2921ba71 2b66f05e 


在 Node2 上 现在 运行 了 两 个 容器 。 在 我 们 的 RC/Pod 定 义 文 件 中 仅 
仅 包含 了 一 个 ， 那 么 这 第 2 个 是 从 哪里 来 的 呢 ? 第 2 个 看 起 来 运行 的 是 
一 个 叫 作 google_containers/pause: latest 的 镜像 ， 而 且 这 个 容器 已 经 有 
端口 映射 到 它 上 面 了 ， 为 什么 是 这 样 呢 ? 让 我 们 深入 容器 内 部 去 看 一 
下 具体 原因 。 使 用 Docker 的 “inspect” 命 令 来 查看 容 需 的 详细 信息 ， 特 
别 要 关注 容器 的 网 络 模型 。 


# docker inspect 6dib99cff4ae | grep NetworkMode 
"NetworkMode": "bridge", 


# docker inspect 37b193a4c633 | grep NetworkMode 


"NetworkMode": 
"Container :6d1b99cff4ae537689ce87d7528F4ba9dbb40ae711ecc0a5 
b3f7c39ff5e5e495", 


ANA RE, FATE Aan MARA, Bla DUE SU 
ix FÉ By HO Eo: KP AYN Bi c A 88 eB fT 
Į “google_containers/pause: latest" #itRH Aas, EEA I DockersA 1A 
的 网 络 模型 bridge; MRI EAEE, (ETE IRC/PodrP 
EUS ITH php-redis# ae, (EH FABER VA BY Dx] 265 BU “ee AT RTS ck TJ TR 
型 ， 指 定 了 映射 目标 容器 为 “google_containers/pause: latest" ° 


我 们 一 起 来 仔细 思考 一 下 这 个 过 程 ， 为 什么 Kubernetes 要 这 人 么 做 
WE? 首先 ， 一 个 Pod 内 的 所 有 容器 都 需要 共用 同一 个 IP 地 址 ， 这 就 意味 
着 一 定 要 使 用 网 络 的 容器 映射 模式 。 然 而 ， 为 什么 不 能 只 局 动 第 1 个 
Pod 中 的 容器 ， 而 将 第 2 个 Pod 内 的 容器 关联 到 第 1 个 容 絮 昵 ?我 们 认为 
Kubernetes 从 两 个 方面 来 考虑 这 个 问题 ， 首 先 ， 如 果 Pod 有 超过 两 个 容 
名 的 话 ， 则 连接 这 些 容 颖 可 能 不 容易 ， 其 次 ， 后 面 的 容 右 还 要 依赖 第 1 
个 被 天 联 的 容 姻 ， 如 有 果 第 2 个 容器 天 联 到 第 1 个 容器 ， 且 第 1 个 容器 死 掉 
的 话 ， 第 2 个 也 将 死 掉 。 启 动 一 个 基础 容器 ， 然 后 将 Pod 内 的 所 有 容 右 
都 连接 到 它 上 面 会 更 容易 一 些 。 因 为 我 们 只 需要 为 基础 的 这 个 
Google_containers/pause 容 塘 执 行 端口 映射 规则 ， 这 也 简化 了 端口 映射 
的 过 程 。 所 以 我 们 的 Pod 的 网 络 模型 类 似 于 图 3.32。 
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10.1.20.4 


Node2 
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图 3.32 ”启动 Pod 后 网 络 模型 
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google containers/pause 7f 88 ° 3.32 有 把 儿 取 巧 地 显示 了 是 
google_containers/pause 容 器 将 问 口 80 的 流量 转发 给 了 相关 的 容器 。 而 
Pause 只 是 逻辑 上 的 ， 并 没有 真 的 这 么 做 。 实 际 上 为 外 的 Web 容 右 直 接 
监 昕 了 这 些 端 口 ， 和 google_containers/pause 容 器 共享 了 同一 个 网 络 堆 
栈 。 这 束 是 为 什么 Pod 内 部 实际 容 絮 的 端口 映 财 都 显示 到 
google_containers/pause 容 器 上 上 了。 我 们 可 以 通过 docker port 命 令 来 检验 
一 下 : 


# docker ps 
CONTAINER ID IMAGE 
37b193a4c633 kubeguide/example-guestbook-php- 
redis 
6dib99cff4ae google containers/pause:latest 
# 


# docker port 6d1b99cff4ae 
80/tcp ->0.0.0.0:80 


Se EPT, google_containers/pause% as XBRE H æ fA oi BE Ik 
Pod 的 Endpoint， 它 实际 上 并 没有 做 更 多 的 事情 。 那 么 Node 呢 ， 它 需 
将 数据 流传 给 google_containers/pause 容 右 吗 ? 我 们 来 检查 一 下 Iptables 
的 规则 ， 看 看 有 什么 发 现 : 


# iptables-save 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
17:15:01 2015 


*nat 


:PREROUTING ACCEPT [0:0] 
: INPUT ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
:DOCKER - [0:0] 
:KUBE-NODEPORT-CONTAINER - [0:0] 
:KUBE-NODEPORT-HOST - [0:0] 
:KUBE-PORTALS-CONTAINER - [0:0] 
:KUBE-PORTALS-HOST - [0:0] 
-A PREROUTING -m comment --comment "handle ClusterIPs; 
NOTE: this must be before the NodePort rules" -j KUBE- 
PORTALS -CONTAINER 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 
-A PREROUTING -m addrtype --dst-type LOCAL -m comment 
--comment "handle service NodePorts; NOTE: this must be the 
last rule in the chain" -j KUBE-NODEPORT CONTAINER 
-A OUTPUT -m comment --comment "handle ClusterIPs; 
NOTE: this must be before the NodePort rules" -j KUBE- 
PORTALS -HOST 
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type 
LOCAL -j DOCKER 
-A OUTPUT -m addrtype --dst-type LOCAL -m comment -- 
comment "handle service NodePorts; NOTE: this must be the 
last rule in the chain 
-A POSTROUTING -s 10.1.20.0/24 ! -o dockerO -j 
MASQUERADE 
-A KUBE-PORTALS-CONTAINER -d 20.1.0.1/32 -p tcp -m 


comment --comment "default/kubernetes:" -m tcp --dport 443 
-j REDIRECT --to-ports 60339 
-A KUBE-PORTALS-HOST -d 20.1.0.1/32 -p tcp -m comment 
--comment "default/kubernetes:" -m tcp --dport 443 -j DNAT 
--to-destination 192.168.1.131:60339 
COMMIT 
# Completed on Thu Sep 24 17:15:01 2015 
# Generated by iptables-save v1.4.21 on Thu Sep 24 
17:15:01 2015 
*filter 
: INPUT ACCEPT [1131:377745] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [1246:209888] 
:DOCKER - [0:0] 
-A FORWARD -o dockerO -j DOCKER 
-A FORWARD -o dockerO -m conntrack --ctstate 
RELATED, ESTABLISHED -j ACCEPT 
-A FORWARD -i dockerO ! -o dockerO -j ACCEPT 
-A FORWARD -i dockerO -o dockerO -j ACCEPT 
-A DOCKER -d 172.17.0.19/32 ! -i dockerO -o dockerO -p 
tcp -m tcp --dport 5000 -j ACCEPT 
COMMIT 


# Completed on Thu Sep 24 17:15:01 2015 


上 面 的 这 些 规则 并 没有 应 用 到 我 们 刚刚 定义 的 Pod。 当 然 ， 
Kubemetes 会 给 每 一 个 Kubemetes 的 节 扩 提供 一 些 默 认 的 服务 ， 上 面 的 
规则 整 古 Kubermetes 的 默认 服务 需要 的 。 关 键 是 ， 我 们 没有 看 到 任何 人 P 


伪装 的 规则 ， 并 且 没有 任何 指向 Pod 10.1.20.4 的 内 部 方向 的 端口 映 
射 。 


第 2 步 : 发 布 一 个 服务 


我 们 已 经 了 解 了 Kubernetes 如 何 处 理 最 基本 的 元 素 Pod 的 连接 问 
题 ， 接 下 来 看 一 下 它 是 如 何 处 理 Service 的 。Service 人 允许 我 们 在 多 个 
Pod 之 间 抽 象 一 些 服务 ， 而 且 ， 服 务 可 以 通过 提供 在 同一 个 Service 的 
多 个 Pod 之 间 的 负载 均衡 机 制 来 支持 水 平 扩展 。 我 们 再 次 将 环境 初始 
化 ， 删 除 刚刚 创建 的 RC/Pod 来 确保 集群 是 空 的 : 


# kubectl stop rc frontend 
replicationcontroller/frontend 
# 
# kubectl get rc 
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 
REPLICAS 
# 


# kubectl get services 


NAME LABELS 
SELECTOR  IP(S) PORT(S) 
kubernetes component=apiserver, provider=kubernetes 


<none>20.1.0.1  443/TCP 
# 
# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


然后 准备 一 个 名 称 为 frontend 的 Service 配 置 文件 : 


apiVersion: v1 
kind: Service 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
ports: 
- port: 80 
# nodePort: 30001 
selector: 
name: frontend 
# type: 


# NodePort 


然后 在 Kubernetes 集 群 中 定义 这 个 服务 : 


# kubectl create -f frontend-service.yaml 
services/frontend 


# kubectl get services 


NAME LABELS SELECTOR 
IP(S) PORT(S) 

frontend name=frontend name=frontend 
20.1.244.75 80/TCP 

kubernetes 

component=apiserver, provider=kubernetes «none» 20.1.0.1 


443/TCP 


服务 正确 创建 后 ， 可 以 看 到 Kubernetes 集 群 已 经 为 这 个 服务 分 配 
了 一 个 虚拟 下地 址 20.1.244.75 ， 这 个 下 地 址 是 在 Kubernetes 的 Portal 
Network 中 分 配 的 。 而 这 个 Portal Networkk 的 地 址 范围 则 是 我 们 在 
Kubmaster 上 局 动 API 服 务 进 程 时 ， 使 用 --service-cluster-ip-range=xx 命 
令 行 参 数 指定 的 : 


# cat /etc/kubernetes/apiserver 
# Address range to use for services 
KUBE_SERVICE_ADDRESSES="- -service-cluster-ip- 


range=20.1.0.0/16" 


这 个 IP 段 可 以 是 任何 段 ， 只 要 不 和 docker0 或 者 物理 网 络 的 子 网 剖 
突 就 可 以 。 选 择 任 意 其 他 网 段 的 原因 是 这 个 网 段 将 不 会 在 物理 网 络 和 
docker0 网 络 上 进行 路 由 。 这 个 Portal Network 针 对 每 一 个 Node 都 有 局 部 
的 特殊 性 ， 实 际 上 它 存 在 的 意义 是 让 容器 的 流量 都 指向 默认 网 天 (也 
就 是 docker0 网 桥 ) 。 在 继续 实验 前 ， 先 登录 到 Nodel 上 看 一 下 我 们 定 
义 服务 后 发 生 了 什么 变化 。 首 先 检查 一 下 Iptables/Netfilter 的 规则 : 


# iptables-save 
-A KUBE-PORTALS-CONTAINER -d 20.1.244.75/32 -p tcp -m 
comment --comment "default/frontend:" -m tcp --dport 80 -j 
REDIRECT --to-ports 59528 
-A KUBE-PORTALS-HOST -d 20.1.244.75/32 -p tcp -m 


comment --comment "default/kubernetes:" -m tcp --dport 80 - 


j DNAT --to-destination 192.168.1.131:59528 


第 1 行 是 挂 在 PREROUTING 链 上 的 端口 重 定向 规则 ， 所 有 的 进 流 
量 如 果 满 足 20.1.244.75: 80， 则 都 会 被 重 定向 到 端口 33761。 第 2 行 是 
挂 在 OUTPUT 链 上 的 目标 地 址 NAT， 做 了 和 上 壕 第 1 行规 则 类 似 的 工 
作 ， 但 针对 的 是 当前 主机 生成 的 外 出 流量 。 所 有 主机 生成 的 流量 都 需 
要 使 用 这 个 DNAT 规 则 来 处 理 。 简 而 言 之 ， 这 两 个 规则 使 用 了 不 同 的 
方式 做 了 类 似 的 事情 ， 束 是 将 所 有 从 节点 生成 的 发 送 给 20.1.244.75: 
80 的 流量 重 定 癌 到 本 地 的 33761 端 口 。 


到 此 为 止 ， 目 标 为 Service IP 地 址 和 端口 的 任何 流量 都 将 被 重 定 问 
到 本 地 的 33761 端 口 。 这 个 端口 连 到 哪里 去 了 呢 ? 这 束 到 了 kube-proxy 
发 挥 作 用 的 地 方 了 。 这 个 kube-proxy 服 务 给 每 一 个 新 创建 的 服务 关联 
了 一 个 随机 的 端口 号 ， 并 且 监 听 那 个 特定 的 端口 ， 为 服务 创建 相关 的 
负载 均衡 对 象 。 在 我 们 的 实验 中 ， 随 机 生成 的 端口 刚好 是 33761。 通 过 
监控 Nodel 上 的 Kubernetes-Service 的 日 志 ， 在 创建 服务 时 ， 我 们 可 以 
看 到 下 面 的 记录 : 


2612 proxier.go:413] Opened iptables from-containers 
portal for service "default/frontend:"on TCP 20.1.244.75:80 
2612 proxier.go:424] Opened iptables from-host portal 


for service "default/frontend:"on TCP 20.1.244.75:80 


现在 我 们 知道 ， 所 有 的 流量 都 被 导入 kube-proxy。 现 在 我 们 需要 
它 完 成 一 些 负载 均衡 的 工作 。 创 建 Replication Controller 并 观察 结果 ， 


下 面 是 Replication Controller 的 配置 文件 : 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: frontend 
labels: 
name: frontend 
spec: 
replicas: 3 
selector: 
name: frontend 
template: 
metadata: 

labels: 
name: frontend 

spec: 

containers: 

- name: php-redis 
image: kubeguide/example-guestbook-php-redis 
env: 

- name: GET HOSTS FROM 
value: env 

ports: 

- containerPort: 80 


# hostPort: 80 


在 集群 发 布 上 述 配置 文件 后 ， 等 竺 并 观察 ， 确 保 所 有 Pod 都 运行 
起 来 了 : 


# kubectl create -f frontend-controller.yaml 

replicationcontrollers/frontend 

# 

# kubectl get pods -o wide 

NAME READY STATUS RESTARTS AGE 
NODE 

frontend-64t8q 1/1 Running 0 5s 
192.168.1.130 

frontend-dzqve 1/1 Running 0 5s 
192.168.1.131 

frontend -x5dwy 1/1 Running 0 5s 
192.168.1.129 


现在 所 有 的 Pod 都 运行 起 来 了 ，Service 将 会 对 匹配 到 标签 
为 “name=frontend” 的 所 有 Pod 进 行人 负载 分 发 。 因 为 Service 选择 匹配 
所 有 的 这 些 Pod， 所 以 我 们 的 负载 均衡 将 会 对 这 3 个 Pod 进 行 分 发 。 现 
在 我 们 做 实验 的 环境 如 图 3.33 所 示 。 
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图 3.33 ”启动 服务 后 的 结构 


Kubernetes 的 kube-proxy 看 起 来 只 是 一 个 夹层 ， 但 实际 上 它 只 是 在 
Node 上 运行 的 一 个 服务 。 上 壕 重 定 癌 规则 的 结果 就 是 针对 目标 地 址 为 
服务 IP 的 流量 ， 将 Kubernetes 的 kube-proxy 变 成 了 一 个 中 间 的 夹层 。 


为 了 查看 具体 的 重 定 疝 动作 ， 我 们 会 使 用 tcpdump 来 进行 网 络 抓 包 
操作 。 目 和 完 ， 安 装 tcpdump: 


yum-yinstall tcpdump 


安装 完成 后 ， 登 录 Nodel1， 运 行 tcpdump 命 令 : 
tcpdump-nn-q-ieno16777736 port80 


需要 捕获 物理 服务 器 以 太 网 接口 的 数据 包 ，Nodel 机 器 上 的 以 太 
网 接口 名 字 叫 作 eno16777736 。 


再 打开 第 1 个 窗口 运行 第 2 个 tcpdump 程 序 ， 不 过 我 们 需要 一 些 人 额外 
的 信息 去 运行 它 ， 即 挂 接 在 docker0 桥 上 的 虚拟 网 卡 Veth 的 名 字 。 我 们 
看 到 只 有 一 个 frontend 容 器 在 Nodel 主 机 上 运行 ， 所 以 可 以 使 用 简单 
的 “ip addr”* 命 令 来 查看 唯一 的 “Veth” 网 络 接口 : 


# ip addr 
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc noqueue 
state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
valid lft forever preferred lft forever 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: enoi16777736: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 
1500 qdisc pfifo fast state UP qlen 1000 
link/ether 00:0c:29:47:6e:2c brd ff:ff:ff:ff:ff:ff 
inet 192.168.1.129/24 brd 192.168.1.255 scope 


global enoi16777736 
valid lft forever preferred lft forever 
inet6 fe80::20c:29ff:fe47:6e2c/64 scope link 
valid lft forever preferred lft forever 
3: docker0O: <NO-CARRIER, BROADCAST, MULTICAST,UP» mtu 
1500 qdisc noqueue state DOWN 
link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff 
inet 10.1.10.1/24 brd 10.1.10.255 scope global 
docker®O 
valid lft forever preferred_lft forever 
inet6 fe80::5484:7aff:fefe:9799/64 scope link 
valid lft forever preferred lft forever 
12: veth0558bfa: «BROADCAST, MULTICAST,UP,LOWER UP» mtu 
1500 qdisc noqueue master dockerO state UP 
link/ether 86:82:e5:c8:5a:9a brd ff:ff:ff:ff:ff:ff 
inet6 fe80::8482:ebff:fec8:5a9a/64 scope link 


valid lft forever preferred lft forever 


复制 这 个 接口 的 名 字 ， 在 第 2 个 窗口 中 运行 tcpdump 命 令 。 
tcpdump -nn -q -i vethO558bfa host 20.1.244.75 


同时 运行 这 两 个 命令 ， 并 且 将 窗口 并 排放 置 ， 以 便 同 时 看 到 两 个 
窗口 的 输出 : 


# tcpdump -nn -q -i eno16777736 port 80 


tcpdump: verbose output suppressed, use -v or -vv for 


full protocol decode 
listening on enoi16777736, link-type EN10MB (Ethernet), 


capture size 65535 bytes 


# tcpdump -nn -q -i vethO558bfa host 20.1.244.75 

tcpdump: verbose output suppressed, use -v or -vv for 
full protocol decode 

listening on veth0558bfa, link-type EN10MB (Ethernet), 


capture size 65535 bytes 


好 了 ， 我 们 已 经 在 同时 捕获 两 个 接口 的 网 络 包 了 “。 这 时 再 局 动 第 3 
个 窗口 ， 运 行 一 个 “docker exec" MERERI 1H) frontend” HJ Z8 
内 部 〈 你 可 以 先 执 行 docker ps 来 获得 这 个 容器 的 ID) 


# docker ps 
CONTAINER ID IMAGE 
268ccdfb9524 kubeguide/example - guestbook -php- 
redis > aun 
6a519772b27e google_containers/pause:latest 


#docker exec -it 268ccdfb9524 bash 
# docker exec -it 268ccdfb9524 bash 


root@frontend-x5dwy :/# 


— HFA SITRA ANB, 3X4 LR] Deo PodB IPH HERV I8] A 
务 了 。 使 用 curl 来 党 试 访问 服务 : 


curl20.1.244.75 


在 使 用 cun 访 问 服务 时 ， 将 在 抓 包 的 两 个 窗口 内 看 到 : 


20:19:45.208948 IP 192.168.1.129.57452 
210.1.30.8.8080: tcp © 

20:19:45.209005 IP 10.1.30.8.8080 > 
192.168.1.129.57452: tcp 0 

20:19:45.209013 IP 192.168.1.129.57452 
210.1.30.8.8080: tcp © 

20:19:45.209066 IP 10.1.30.8.8080 > 


192.168.1.129.57452: tcp 0 


20:19:45.209227 IP 10.1.10.5.35225 > 20.1.244.75.80: 
tcp 0 

20:19:45.209234 IP 20.1.244.75.80 >10.1.10.5.35225: 
tcp 0 

20:19:45.209280 IP 10.1.10.5.35225 » 20.1.244.75.80: 
tcp 0 

20:19:45.209336 IP 20.1.244.75.80 >10.1.10.5.35225: 


tcp 0 


这 些 信息 说 明了 什么 问题 呢 ? 让 我 们 在 网 络 图 上 用 实 线 标 出 第 1 个 
窗口 中 网 络 抓 包 信息 的 含义 (物理 网 卡 上 的 网 络 流量 ) ， 并 用 虚线 标 


出 第 2 个 窗口 中 网 络 抓 包 信息 的 含义 (docker0 网 桥 上 的 网 络 流量 ) ， 


如 图 3.34 所 示 。 
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图 3.34 ”数据 流动 情况 图 1 


注意 ， 图 3.34 中 ， 虚 线 绕 过 了 Node3 的 kube-proxy， 这 么 做 是 因为 
Node3 上 的 kube-proxy 没 有 参与 这 次 网 络 交 互 。 换 句 话 说 ，Nodel 的 
kube-proxy 服 务 直 接 和 负载 均衡 到 的 Pod 进 行 网 络 交 互 。 


在 查看 第 2 个 捕获 包 的 窗口 时 ， 我 们 能 够 站 在 容器 的 视角 看 这 些 流 
量 。 首 先 ， 容 器 尝试 使 用 20.1.244.75: 80 打 开 TCP 的 Socket 连 接 。 同 


时 ， 我 们 还 可 以 看 到 从 服务 地 址 20.1.244.75 返 回 的 数据 。 从 容器 的 视 
角 来 看 ， 整 个 交互 过 程 都 是 在 服务 之 间 进 行 的 。 但 是 在 查看 一 个 捕获 
包 的 窗口 时 CRO) ， 我 们 可 以 看 到 物理 机 之 间 的 数据 交互 ， 
可 以 看 到 一 个 TCP 连 接 从 Nodel 的 物理 地 址 (192.168.1.129) Ait, A 
接连 接 到 运行 Pod 的 主机 Node3 (192.168.1.131) ° AMEZ, 
Kubernetes 的 kube-proxy 作 为 一 个 全 功能 的 代理 服务 器 管理 了 两 个 独立 
的 TCP 连 接 : 一 个 是 从 容器 到 kube-proxy: 男 一 个 是 从 kube-proxy 到 人 负 
载 均衡 的 目标 Pod。 


如 果 我 们 清理 一 下 捕获 的 记录 ， 再 次 运行 curl， 则 还 可 以 看 到 网 
络 沉 量 修仙 载 均衡 转发 到 男 一 个 节 态 Node2 上 了 。 


20:19:45.208948 IP 192.168.1.129.57485 
210.1.20.6.8080: tcp © 

20:19:45.209005 IP 10.1.20.6.8080 > 
192.168.1.129.57485: tcp 0 

20:19:45. 209013 IP 192.168.1.129.57485 
210.1.20.6.8080: tcp © 

20:19:45.209066 IP 10.1.20.6.8080 > 
192.168.1.129.57485: tcp 0 


20:19:45.209227 IP 10.1.10.5.38026> 20.1.244.75.80: 
tcp 0 

20:19:45.209234 IP 20.1.244.75.80 >10.1.10.5.38026: 
tcp 0 

20:19:45.209280 IP 10.1.10.5.38026> 20.1.244.75.80: 


tcp 0 


20:19:45.209336 IP 20.1.244.75.80 >10.1.10.5.38026: 
tcp 0 


这 一 次 ，Kubernetes 的 Proxy 将 选择 运行 在 Node2 (10.1.20.1) 上 面 
的 Pod 作 为 负载 均衡 的 目的 。 网 络 流动 图 如 图 3.35 所 示 。 
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图 3.35 ”数据 流动 情况 图 2 


到 这 里 ， 你 肯定 已 经 知道 另外 一 个 可 能 的 负载 均衡 的 路 由 结 采 了 
HE, o 


第 4 革  Kubernetes7T A 18 pgj 


本 章 将 引入 REST 的 概念 ， 详 细 说 明 Kubernetes API， 并 举例 说 明 
如 何 基于 Jersey 和 Fabric8 框 架 访 问 Kubernetes API， 深 入 分 析 基 于 这 两 
个 框 染 访问 Kubernetes API 的 优 缺 点 。 下面 从 REST 开 始 说 起 。 


41 REST zi 


REST (Representational State Transfer) 是 由 Roy Thomas Fielding 
博士 在 他 的 论文 Architectural Styles and the Design of Network-based 
Software Architectures "F $e i H— ARE ° RESTA A ap fh AE 
媒体 系统 设计 的 一 种 架构 风格 ， 而 不 是 标准 。 


基于 Web 的 如 构 实际 上 束 是 各 种 规范 的 集合 ， 这 些 规 范 共 同 组 成 
了 Web 染 构 ， 比 如 HTTP、 客 户 端 服务 句 模 式 都 是 规范 。 每 当 我 们 在 原 
有 规范 的 基础 上 增加 新 的 规范 时 ， 殊 会 形成 新 的 染 构 。 而 REST 正 是 这 
样 一 种 架构 ， 它 结合 了 一 系列 规范 ， 形 成 了 一 种 新 的 基于 Web 的 架构 
风格 。 


传统 的 Web 应 用 大 多 是 B/S 染 构 ， 涉 及 如 下 规范 。 


(1) 客户 -服务 器 : 这 种 规范 的 提出 ， 改 善 了 用 户 接口 跨 多 个 平 
台 的 可 移植 性 ， 并 且 通 过 人 簿 化 服务 喜 组 件 ， 改 善 了 系统 的 可 伸缩 性 。 
最 为 关键 的 是 通过 分 离 用 户 接 口 和 数据 存储 ， 使 得 不 同 的 用 户 终 端 共 
译 相 同 的 数据 成 为 可 能 。 


(2) 无 状态 性 : 无 状态 性 是 在 客户 -服务 器 约束 的 基础 上 添加 的 
又 一 层 规范 ， 它 要 求 通信 必须 在 本 质 上 是 无 状态 的 ， 即 从 客户 端 到 服 
务 怖 的 每 个 request 都 必须 包含 理解 该 request 所 必需 的 所 有 信息 。 这 个 
规范 改善 了 系统 的 可 见 性 〈 无 状态 性 使 得 客户 端 和 服务 器 端 不 必 保 存 
对 方 的 详细 信息 ， 服 务 器 只 需要 处 理 当 前 的 request， 而 不 必 了 解 所 有 
request 的 历史 ) 、 可 靠 性 (无 状态 性 减少 了 服务 器 从 局 部 错误 中 恢复 


的 任务 量 ) 、 可 伸缩 性 〈 无 状态 性 使 得 服务 器 端 可 以 很 容易 地 释放 资 
源 ， 因 为 服务 器 端 不 必 在 多 个 request 中 保存 状态 ) 。 同 时 ， 这 种 规范 
的 缺点 也 是 显而易见 的 ， 由 于 不 能 将 状态 数据 保存 在 服务 右上 ， 因 此 
增加 了 在 一 系列 request 中 发 送 重 复数 据 的 开销 ， 严 重 降低 了 效率 。 


(3) 缓存 :为 了 改善 无 状态 性 融 来 的 网 络 的 低 效 性 ， 我 们 添加 了 
绥 存 约束 。 绥 存 约束 允许 隐 式 或 显 式 地 标记 一 个 response 中 的 数据 ， 赋 
了 予 了 客户 端 缓存 response 数 据 的 功能 ， 这 样 承 可 以 为 以 后 的 request 共 用 
缓存 的 数据 ， 部 分 或 全 部 地 消除 一 部 分 交互 ， 提 高 了 网 络 歼 率 。 但 是 
由 于 客户 端 缓存 了 信息 ， 所 以 增加 了 客户 端 与 服务 器 数据 不 一 致 的 可 
能 性 ， 从 而 降低 了 可 靠 性 。 


B/S 架 构 的 优点 是 部 署 非常 方便 ， 在 用 户 体验 方面 却 不 很 理想 。 为 
了 改善 这 种 情况 ， 我 们 引入 了 REST。REST 在 原 有 架构 上 增加 了 三 个 
新 规范 : 统一 接口 、 分 层 系 统 和 按 需 代码 。 


(1) 统一 接口 : REST 架 构 风 格 的 核心 特征 就 是 强调 组 件 之 间 有 
一 个 统一 的 接口 ， 表 现 为 在 REST 世 界 里 ， 网 络 上 的 所 有 事物 都 被 抽象 
为 资源 ，REST 通 过 通用 的 链接 锋 接 口 对 资源 进行 操作 。 这 样 设计 的 好 
处 是 保证 系统 提供 的 服务 都 是 解 耦 的 ， 极 大 地 简化 了 系统 ， 从 而 改善 
了 系统 的 交互 性 和 可 重用 性 。 


(2) 分 层 系统 : 分 层 系统 规则 的 加 入 提高 了 各 种 层次 之 间 的 独立 
性 ， 为 整个 系统 的 复杂 性 设置 了 边界 ， 通 过 封 狐 遗留 的 服务 ， 使 新 的 
服务 句 免 受 遗 留 客 户 端 的 影响 ， 也 提高 了 系统 的 可 伸缩 性 。 


(3) 按 需 代码 ，REST 人 允许 对 客户 端 功 能 进行 扩展 。 比 如 ， 通 过 
下 载 并 执行 applet 或 脚本 形式 的 代码 来 扩展 客户 端的 功能 。 但 这 在 改善 


系统 可 扩展 性 的 同时 降低 了 可 见 性 ， 所 以 它 只 是 REST 的 一 个 可 选 约 
Hio 


REST 架 构 是 针对 Web 应 用 而 设计 的 ， 其 目的 是 为 了 降低 开发 的 复 
杂 性 ， 提 高 系统 的 可 伸缩 性 。REST 提 出 了 如 下 设计 准则 。 


(1) 网 络 上 的 所 有 事物 都 被 抽象 为 资源 (Resource) 


(2) 每 个 资源 对 应 一 个 唯一 的 资源 标识 符 ” (Resource 
Identifier) 。 


(3) 通过 通用 的 连接 器 接口 (Generic Connector Interface) 对 资 
源 进行 操作 。 


(4) 对 资源 的 各 种 操作 不 会 改变 资源 标识 符 。 


(5) 所 有 的 操作 都 是 无 状态 的 (Stateless) 


REST 中 的 资源 所 指 的 不 是 数据 ， 而 是 数据 和 表现 形式 的 组 合 ， 比 
如 “最 新 访问 的 10 位 会 员 ” 和 “最 活跃 的 10 位 会 员 ” 在 数据 上 可 能 有 重 县 
或 者 完全 相同 ， 而 由 于 它们 的 表现 形式 不 同 ， 所 以 被 归 为 不 同 的 资 
源 ， 这 也 就 是 为 什么 REST 的 全 名 是 Representational State Transfer。 资 
源 标识 符 就 是 URI (Uniform Resource Identifier) , 不管 是 图 片 、Word 
还 是 视频 文件 ， 甚 至 只 是 一 种 虚拟 的 服务 ， 也 不 管 是 xml、txt 还 是 其 
他 文件 格式 ， 全 部 通过 URI 对 资源 进行 唯一 标识 。 


REST 是 基于 HTTP 的 ， 任 何 对 资源 的 操作 行为 都 通过 HTTP 来 实 
现 。 以 往 的 web 开发 大 多 数 用 的 是 HITP 中 的 GET 和 了 POST 方法 ， 很 少 
使 用 其 他 方法 ， 这 实际 上 是 因为 对 HTTP 的 片面 理解 造成 的 。HTTP 不 
仅仅 是 一 个 简单 的 运载 数据 的 协议 ， 而 且 是 一 个 具有 丰富 内 洱 的 网 络 


软件 的 协议 ， 它 不 仅 能 对 互联 网 资源 进行 唯一 定位 ， 还 能 告诉 我 们 如 
何 对 该 资源 进行 操作 。HTTP 把 对 一 个 资源 的 操作 限制 在 4 种 方法 内 : 
GET、POST、PUT 和 DELETE， 这 正 是 对 资源 CRUD 操 作 的 实现 。 由 

资源 和 URI 是 一 一 对 应 的 ， 在 执行 这 些 操作 时 URI 没 有 变化 ， 和 以 往 
的 Web 开 发 有 很 大 的 区 别 ， 所 以 极 大 地 简化 了 Web 开 发 ， 也 使 得 URI 可 
以 被 设计 成 更 为 直观 地 反映 资源 的 结构 。 这 种 URI 的 设计 被 称 作 
RESTfu 的 URI， 为 开发 人 员 引 入 了 一 种 新 的 思维 方式 : 通过 URL 来 设 
计 系 统 结构 。 当 然 了 ， 这 种 设计 方式 对 于 一 些 特定 情况 也 是 不 适用 
的 ， 也 就 是 说 不 是 所 有 URI 都 适用 于 RESTful 。 


REST 之 所 以 可 以 提高 系统 的 可 伸缩 性 ， 融 是 因为 它 有 要 求 所 有 操作 
都 是 无 状态 的 。 由 于 没有 了 上 下 文 《Context) 的 约束 ， 做 分 布 式 和 集 
群 时 就 更 为 简单 ， 也 可 以 让 系统 更 为 有 效 地 利用 缓冲 池 (Pool) ， 并 
且 由 于 服务 絮 端 不 需要 记录 客户 并 的 一 系列 访问 ， 也 整 减少 了 服务 右 
端的 性 能 损耗 。 


Kubernetes API 也 符合 RESTfu] 规 范 ， 下 面 对 其 进行 介绍 。 


4.2 Kubernetes APIVÉRE 


4.2.1 Kubernetes API 概 壕 


Kubernetes API 是 集群 系统 中 的 重要 组 成 部 分 ，Kubernetes 中 各 种 
资源 OTR) 的 数据 通过 该 API 接 口 被 提交 到 后 端的 持久 化 存储 
(etcd) 中 ，Kubernetes 集 群 中 的 各 部 件 之 间 通 过 该 API 接 口 实现 解 耦 
合 ， 同 时 Kubernetes 集 群 中 一 个 重要 且 便 捷 的 管理 工具 kubect 也 是 通过 
访问 该 API 接 口 实现 其 强大 的 管理 功能 的 。Kubernetes API 中 的 资源 对 
象 都 拥有 通用 的 元 数据 ， 资 源 对 象 也 可 能 存在 骨 套 现象 ， 比 如 在 一 个 
Pod 里 面向 套 多 个 Container。 创 建 一 个 API 对 象 是 指 通 过 API 调 用 创建 
一 条 有 意义 的 记录 ， 该 记录 一 旦 被 创建 ，Kubernetes 将 确保 对 应 的 资 
源 对 象 会 被 目 动 创建 并 托管 维护 。 


在 Kubernetes 系 统 中 ， 大 多 数 情 况 下 ，API 定 义 和 实 现 都 符合 标准 
的 HTTP REST 格 式 ， 比 如 通过 标准 的 HITP 动 词 (POST ^ PUT ` 
GET ` DELETE) 来 完成 对 相关 资源 对 象 的 查询 、 创 建 、 修 改 、 删 除 
等 操作 。 但 同时 Kubernetes 也 为 某 些 非 标 准 的 REST 行 为 实现 了 附加 的 
API 接 口 ， 例 如 Watch 某 个 资源 的 变化 、 进 入 容器 执行 某 个 操作 等 。 另 
外 ， 某 些 API 接 口 可 能 违背 严格 的 REST 模 式 ， 因 为 接口 不 是 返回 单一 
的 JSON 对 象 ， 而 是 返回 其 他 类 型 的 数据 ， 比 如 JSON XT 25 Tt 

(Stream) 或 非 结 构 化 的 文本 日 志 数 据 等 。 


Kubermnetes 开 发 人 员 认 为 ， 任 何 成 功 的 系统 都 会 经 历 一 个 不 断 成 
长 和 不 断 适 应 各 种 变更 的 过 程 。 因 此 ， 他 们 期 望 Kubernetes API 是 不 断 
变更 和 增长 的 。 同 时 ， 他 们 在 设计 和 开发 时 ， 有 意识 地 兼容 了 已 存在 
的 客户 需求 。 通 常 ， 新 的 API 资 源 (Resource) 和 新 的 资源 域 不 希望 被 
频繁 地 加 入 系统 。 资 源 或 域 的 删除 需要 一 个 严格 的 审核 流程 。 


为 了 方便 查阅 API 接 口 的 详细 定义 ，Kubernetes 使 用  swagger-ui 
fe Dt AP] dE EXE 查询 功能 ， 其 FB 网 为 
http://kubernetes.io/third_party/swagger-ui/ ，Kubernetes 开 发 团队 会 定期 
更 新 、 生 成 UI 及 文档 。Swagger UI 是 一 款 RESTAPI 文 档 在 线 自动 生成 
和 功能 测试 软件 ， 关 于 Swagger 的 内 容 请 访问 官网 http://swagger.io。 


1B 47 Æ Master P 5i, EA API Server 进 程 同 时 提供 了 swagger-ui 的 访 
问 地 址 : http://<master-ip>: <master-port>/swagger-ui/。 假设 我 们 的 
API Server 安 装 在 192.168.1.128 服 务 器 上 ， 绑 定 了 8080 端 口 ， 则 可 以 通 
过 访问 http://192.168.1.128: 8080/swagger-ui/ 来 查看 API 人 信息， 如 图 4.1 
所 示 。 


@ Swagger UI x WI 
€ > C [O kubemetesio/third party/swagger-ui/#/ Qm = 


t} swagger http-//kubemetes.io/third_party/swagger-ui/. /./swagger-spec api ke 


api : get available API versions Show/Hide | List Operations | Expand Operations 
api/v1 : API at /api/v1 version v1 Show/Hide | List Operations | Expand Operations 
version : git code version from which this is built Show/Hide | List Operations | Expand Operations 
[ sase unt: / J [5] 


图 4.1 swagger-ui 


单 击 api/v1 可 以 查看 所 有 API 的 列表 ， 如 图 4.2 所 示 。 


j @ Swagger UI x XS { Aa r 
€ > C [D kubernetesio/third party/swagger-ui/e/ 


t swagger http./kubernetes io'third party/swagger-ui/ / /swagger-spec Explore 


api: get available API versions Show/Hide List Operations | Expand Operations 
api/v1 : API at /api/v1 version v1 Show/Hide List Operations ^ Expand Operations 
| ros | /api/v1/namespaces/{namespace}/bindings create a Binding 
E /api/v1/bindings create a Binding 
ES /api/v1/namespaces/{namespace}/componentstatuses list objects of kind ComponentStatus 
ES /api/v1/namespaces/{namespace}/componentstatuses/{name} read the specified ComponentStatus 
ES Japi/vi/componentstatuses list objects of kind ComponentStatus 
ES /api/v1/namespaces/{namespace}/endpoints list or watch objects of kind Endpoints 
ES 20i1/namespaces/inamespaceendpoints create a Endpoints 


ES /api/v1 /watch/namespaces/{namespace}/endpoints watch individual changes to a list of Endpoints 


ER 201 namespaces/inamespace}/endpoints/{name} delete a Endpoints 


图 4.2 ”查看 API 列 表 


以 create a Pod 为 例 ， 找 到 Rest API AY Ui I] BR TA 
为 : /api/vl/namespaces/{namespace}/pods， 如 图 4.3 所 示 。 


/api/v1/namespaces/{namespace}/pods create a Pod 


图 4.3 Create a Pod API 


单 击 链接 展开 ， 即 可 查看 详细 的 API 接 口 说 明 ， 如 图 4.4 所 示 。 


€ Swagger UI x Wn 
€oc!» 


Ea Japi/v1/namespaces/{namespaceW/pods 


Response Class (Status 200) 
Schema 


图 4.4 Create a Pod API 详 细 说 明 


单 击 Model 链 接 ， 则 可 以 查看 文本 格式 显示 的 API 接 口 朱 述 ， 如 图 
4.5 所 示 。 


(9 Swagger Ul x 


< c kubernetes.io/third party, yger-ui/#!/api%e2Fv 1 /createName: 


Ea /api/v1/namespaces/{namespace}/pods create a Pod 


ass (Status 200) 


Pn v1.Pod{ 


kind (string, optional: kind of object, in CamelCase; 
apiVersion | 
metadata 
spec (v1.P. 
status (v1 
} 
v1.ObjectMeta { 
name (str 
http;/r 
generateName ( 
name if is not s 


HEAD/docs/apl-co 
8s.Jo/HEAD/docs/api-conve 


not be updated; see http; 
sion of the schema the object should have; se 
jonah, 


ional) 


P. 


is, optional) 


Lo hat identifies 


an object. Must be unique within a namespace: cannot be updated; see 


same validation rules as name; optional, and is applied only 


led; see http: 


namespace (string, optional}: names NS LABEL; cannot be updates 
selfLink (string, optional). URL for ject; populated by the system, read-only 
uid (string, optional) unique UUID across space and time; p 


f the object; must be a 


see http.//re 


ulated by the system; read-only; see http-//releases k&s.ic 


be used by clie 


dified back to th 


resourceVersion (string, optional: string that identifies the internal version of this object that 


popt 
http 
ge neration (in 
creationTimestamp (string, optional 
/ kBs.io/HEAD/docs/api-c 
nTimestamp (string, optional: R 
-only; if not set, graceful de 


id-only; value mu: 


t be treated as opaque by c lients and pas 


3339 date and time at which the abje 


hich the object will be delet 


vas not been requested 
ined, optionah, 
annotations (undefined, optional 
} 
v1.podspec ( 
volum 
httpz//r 
containers |/ 


ist of volumes that can be mounted by containers belonging to the 
lumes.md, 


'e must be 


ainer)): list of containers belonging to the pod; cannot be updated; containers cannot currently be added or removed; t 


at least one c 


restartPolicy (s:r in the pod; one of Always, OnFailure, Never; defaults to Always; see 


ht 


licy for all container 


rtpolicy, 


terminationGracePeriodSecon s (in d in delete request; 
ead: the gr 


re forcibly halted v 


nal: optional duration in seconds the pod needs to terminate gracefully; may be dec 


value must be non-negative 
period is tl 


indicates delete immediately: if this value is not set. the default grace period wil 
5 running in the pod are sent a terminatio 


duration in secon: 


and the time w 


图 4.5 Create a Pod API 文 本 格式 详细 说 明 


我 们 看 到 ， 在 Kubernetes API 中 ， 一 个 API 的 顶层 (Top Level) 元 
z& H1kind ` apiVersion 、metadata、spec 和 status 等 儿 个 部 分 组 成 ， 接 下 
来 ， 我 们 分 别 对 这 几 个 部 分 进行 说 明 。 


kind 表 明 对 象 有 以 下 三 大 类 别 


(1) 对 象 (objects) : 代表 在 系统 中 的 一 个 永久 资源 (实体 ) ， 
例如 Pod、RC、Service、Namespace 及 Node 等 。 通 过 操作 这 些 资 源 的 
属性 ， 客 户 端 可 以 对 该 对 象 进行 创建 、 修 改 、 删 除 和 获取 操作 


(2) 列表 (list) : 一 个 或 多 个 资源 类 别 的 集合 。 列 表 有 一 个 通 


用 元 数据 的 有 限 集合 。 所 有 列表 (lists) 通过 “items” 域 获得 对 象 数 


组 ， 例 如 PodLists 、ServiceLists、NodeLists。 大 部 分 定义 在 系统 中 的 


对 象 都 有 一 个 返回 所 有 资源 (resource) 集合 的 端点 ， 以 及 零 到 多 个 返 
回 所 有 资源 集合 的 子 集 的 端点 。 某 些 对 象 有 可 能 是 单 例 对 象 

(singletons) ， 例 如 当前 用 户 、 系 统 默认 用 户 等 ， 这 些 对 象 没 有 列 
Fo 


(3) 简单 类 别 (simple) : 该 类 别 包 含 作 用 在 对 象 上 的 特殊 行为 
和 非 持 久 实 体 。 该 类 别 限制 了 使 用 范围 ， 它 有 一 个 通用 元 数据 的 有 限 
集合 ， 例 如 Binding、Status。 


apiVersion 表 明 API 的 版 本 号 ， 当 前 版 本 默认 只 文 持 v1。 


Metadata 是 资源 对 象 的 元 数据 定义 ， 是 集合 类 的 元 素 类 型 ， 包 仿 
一 组 由 不 同名 称 定 义 的 属性 。 在 Kubernetes 中 每 个 资源 对 象 都 必须 包 
含 以 下 3 种 Metadata ° 


(1) namespace: 对 象 所 属 的 命名 空间 ， 如 果 不 指 定 ， 系 统 则 会 
将 对 象 置 于 名 为 “default”* 的 系统 命名 空间 中 。 


(2) name: 对 象 的 名 字 ， 在 一 个 命名 空间 中 名 字 应 具备 唯一 


PE e 


(3) uid: 系统 为 每 个 对 象 生 成 的 唯一 ID ， 符 合 RFC 4122 规 范 的 
定义 。 

此 外 ， 每 种 对 象 还 应 该 包含 以 下 几 个 重要 元 数据 。 

(1) labels: 用 户 可 定义 的 “标签 ”"， 键 和 值 都 为 字符 串 的 map， 是 


对 象 进行 组 织 和 分 类 的 一 种 手段 ， 通 常用 于 标签 选择 器 (Label 
Selector) ， 用 来 匹配 目标 对 象 。 


(2) annotations: 用 户 可 定义 的 “注解 ”>， 键 和 值 都 为 字符 串 的 
map， 被 Kubernetes 内 部 进程 或 者 某 些 外 部 工具 使 用 ， 用 于 存储 和 获取 
天 于 该 对 象 的 特定 元 数据 。 


(3) resourceVersion: 用 于 识别 该 资源 内 部 版 本 号 的 字符 串 ， 在 
用 于 Watch 操作 时 ， 可 以 避免 在 GET 操 作 和 下 一 次 watch 操 作 之 间 造 成 
的 信息 不 一 致 ， 客 户 端 可 以 用 它 来 判断 资源 是 否 改变 。 该 值 应 该 被 客 
户 端 看 作 不 透明 ， 且 不 做 任何 修改 就 返回 给 服务 端 。 客 户 端 不 应 该 假 
定 版 本 信息 具有 跨 命名 空间 、 跨 不 同 资源 类 别 、 跨 不 同 服务 器 的 含 
Yo 


(4) creationTimestamp: 系统 记录 创建 对 象 时 的 时 间 惟 ， 符 合 
RFC 3339 规 范 。 


(5) deletionTimestamp: 系统 记录 删除 对 象 时 的 时 间 戳 ， 符 合 
RFC 3339 规 范 。 


(6) selfLink: 通过 API 访 问 资源 自身 的 URL ， 例 如 一 个 Pod 的 
link 可 能 是 /api/vl/namespaces/default/pods/frontend-o8bg4。° 


spec 是 集合 类 的 元 素 类 型 ， 用 户 对 需要 管理 的 对 象 进行 详细 摘 壕 
的 主体 部 分 都 在 spec 里 给 出 ， 它 会 被 Kubernetes 持 和 久 化 到 etcd 中 保存 ， 
系统 通过 spec 的 描述 来 创建 或 更 新 对 象 ， 以 达到 用 户 期 望 的 对 象 运行 
状态 。spec 的 内 容 既 包括 用 户 提 供 的 配置 设置 、 默 认 值 、 属 性 的 初始 
化 值 ， 也 包括 在 对 象 创建 过 程 中 由 其 他 相关 组 件 (例如 schedulers、 
auto-scalers) 创建 或 修改 的 对 象 属性 ， 比 如 Pod 的 Service IP 地 址 。 如 果 
spec 被 删除 ， 那 么 该 对 象 将 会 从 系统 中 被 删除 。 


Status 用 于 记录 对 象 在 系统 中 的 当前 状态 信息 ， 它 也 是 集合 类 元 素 
类 型 ，status 在 一 个 目 动 处 理 的 进程 中 被 持久 化 ， 可 以 在 流转 的 过 程 中 
生成 。 如 果 观 察 到 一 个 资源 丢失 了 它 的 状态 (Status) ， 则 该 丢失 的 状 
态 可 能 被 重新 构造 。 以 Pod 为 例 ，Pod 的 status 信 息 主 要 包括 
conditions、containerStatuses、hostIP、phase、podIP、startTime 等 。 其 


中 比较 重要 的 两 个 状态 属性 如 下 。 


(1) phase: 描述 对 象 所 处 的 生命 周期 阶段 ，phase 的 典型 值 
是 “Pending (创建 中 ) ”Running”Active (正在 运行 
FH) ”或 “Terminated (已 终结 ) ”， 这 几 种 状态 对 于 不 同 的 对 象 可 能 
轻微 的 差别 ， 此 外 ， 关 于 当前 phase 附 加 的 详细 说 明 可 能 包含 在 其 他 域 
中 o 


(2) condition: 表示 条 件 ， 由 条 件 类 型 和 状态 值 组 成 ， 目 前 仅 有 
一 种 条 件 类 型 Ready， 对 应 的 状态 值 可 以 为 True、False 或 Unknown。 一 
个 对 象 可 以 具备 多 种 condition， 而 condition 的 状态 值 也 可 能 不 断 发 生 
变化 ，condition 可 能 附带 一 些 信息 ， 例 如 最 后 的 探测 时 间或 最 后 的 转 
变 时 间 。 


4.2.2 ”API 版 本 


为 了 在 兼容 旧版 本 的 同时 不 断 升 级 新 的 API，Kubernetes 提 供 了 多 
版 本 API 的 文 持 能 力 ， 每 个 版 本 的 API 通 过 一 个 版 本 号 路 径 前 缀 进行 区 
分 ， 例 如 /apivlbeta3。 通 常情 况 下 ， 新 旧 几 个 不 同 的 API 版 本 都 能 溯 
蔓 所 有 的 Kubermetes 资 源 对 象 ， 在 不 同 的 版 本 之 间 这 些 API 接 口 存 在 一 
些 细微 差别 。Kubernetes 开 发 团队 基于 API 级 别 选 择 版 本 而 不 是 基于 资 
源 和 域 级 别 ， 是 为 了 确保 API 能 够 描述 一 个 清晰 的 连续 的 系统 资源 和 
行为 的 视图 ， 能 够 控制 访问 的 整个 过 程 和 控制 实验 性 API 的 访问 。 


API 及 版 本 发 布 建议 描述 了 版 本 升级 的 当前 思路 。 版 本 vlbetal ^ 
vlbeta2 和 vlibeta3 为 不 建议 使 用 (Deprecated) 的 版 本 ， 请 尽快 转 到 v1 
版 本 。 在 2015 年 6 月 4 日 ，Kubernetes v1 版 本 API 正 式 发 布 。 版 本 
vlbetal 和 vlbeta2API 在 2015 年 6 月 1 日 被 删除 ， 版 本 vlbeta3API 在 2015 
年 7 月 6 日 被 删除 。 


4.2.3 ”API 详细 说 明 


API 资 源 使 用 REST 模 式 ， 具 体 说 明 如 下 。 


(1) GET< 资 源 名 的 复数 格式 >: 获得 某 一 类 型 的 资源 列表 ， 例 
如 GET/pods 返 回 一 个 Pod 资 源 列表 。 


(2) POST/< 资 源 名 的 复数 格式 >: 创建 一 个 资源 ， 该 资源 来 自用 
户 提供 的 JSON 对 象 。 


(3) GET/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 名 称 
(Name) 获得 单个 资源 ， 例 如 GET/pods/first 返 回 一 个 名 称 为 “first* 的 
Pod ° 


(4) DELETE/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 名 字 删 除 
单个 资源 ， 在 删除 选项 (DeleteOptions) 中 可 以 指定 优雅 删除 (Grace 
Deletion) 的 时 间 (GracePeriodSeconds) ， 该 可 选项 表明 了 从 服务 端 
接收 到 删除 请 求 到 资源 被 删除 的 时 间 间 隔 (单位 为 秒 ) 。 不 同 的 类 别 

(Kind) 可 能 为 优雅 删除 时 间 (Grace Period) 申明 默认 值 。 用 户 提交 
的 优雅 删除 时 间 将 履 盖 该 默认 值 ， 包 括 值 为 0 的 优雅 删除 时 间 。 


(5) PUT/< 资 源 名 复数 格式 >/< 名 字 >: 通过 给 出 的 资源 名 和 客户 
端 提供 的 JSON 对 象 来 更 新 或 创建 资源 。 


(6) PATCH/< 资 源 名 复数 格式 >/< 名 字 >， 选择 修改 资源 详细 指定 
的 域 。 


对 于 PATCH 操作 ， 目 前 Kubernetes API 28 xf TH M HJ HTTP & 
部 “Content-Type” 对 其 进行 识别 。 


目前 文 持 以 下 三 种 类 型 的 PATCH 操作 。 


(1) JSON Patch, Content-Type: application/json-patch+json ° TE 
RFC6902 的 定义 中 ，JSON Patch 是 执行 在 资源 对 象 上 的 一 系列 操作 ， 
例如 {“op”: “add”, “path”: “/a/b/c”, “value”: [*foo", “bar’]} » 详情 
请 查看 RFC6902 说 明 ， 网 址 为 HTTPs: //tools.ietf.org/html/rfc6902 ° 


ro) Merge Patch , Content-Type :  application/merge-json- 
patch+json ° TERFC7386HJ E X. F, Merge Patch 必 须 包 含 对 一 个 资源 对 
象 的 部 分 描述 ， 这 个 资源 对 象 的 部 分 描述 吏 是 一 个 JSON 对 象 。 该 
JSON 对 象 被 提交 到 服务 端 ， 并 和 服务 端的 当前 对 象 合并 ， 从 而 创建 一 
个 新 的 对 象 。 详 ff 请 查看 RFC73862 vi BH , W Bb WW 
HTTPs: //tools.ietf.org/html/rfc7386 ° 


(3) Strategic Merge Patch , Content-Type: application/strategic- 
merge-patch+json ° Strategic Merge Patch 是 一 个 定制 化 的 Merge Patch 实 
现 。 接 下 来 将 详细 讲解 Strategic Merge Patch ° 


在 标准 的 JSON Merge Patch , Seas. dodi (merge) 
的 ,但 是 资源 对 象 中 的 列表 域 总 是 被 蔡 换 的 。 通 常 这 不 是 用 户 所 希望 
的 。 例 如 ， 我 们 通过 下 列 定义 创建 一 个 Pod 资 源 


spec: 
containers: 
- name: nginx 


image: nginx-1.0 


接着 我 们 希望 添加 一 个 容器 到 这 个 Pod 中 ， 代 码 和 上 传 的 JSON 对 
象 如 下 所 示 : 


PATCH /api/vi/namespaces/default/pods/pod-name 
spec: 
containers: 
- name: log-tailer 


image: log-tailer-1.0 


如 果 我 们 使 用 标准 的 Merge Patch， 则 其 中 的 整个 容器 列表 将 被 单 
个 的 “log-tailer” 容 器 所 苦 换 。 然 而 我 们 的 目的 是 两 个 容 絮 列表 能 够 合 
des 


为 了 解决 这 个 问题 ，Strategic Merge Patch 通 过 添加 元 数据 到 API 对 
象 中 ， 并 通过 这 些 新 元 数据 来 决定 哪个 列表 被 合并 ， 哪 个 列表 不 被 合 
并 。 当 前 这 些 元 数据 作为 结构 标签 ， 对 于 API 对 象 目 喘 来 说 是 合法 
的 。 对 于 客户 端 来 说 ， 这 些 元 数据 作为 Swagger annotations 也 是 合法 
的 。 在 上 壕 例 子 中 ， 回 “containers” 中 添加 “patchStrategy” 域 ， 且 它 的 值 
为 “merge”， 通 过 添加 “patchMergeKey”， 它 的 值 为 “hame”。 也 就 十 
说 ，“containers” 中 的 列表 将 会 被 合并 而 不 是 蔡 换 ， 合 并 的 依据 
为 “name” 域 的 值 。 


此 外 ，Kubernetes API 添 加 了 资源 变动 的 “观察 者 ”模式 的 API 接 
O o 


。 GET/watch/< 资 源 名 复数 格式 >: 随时 间 变 化 ， 不 断 接 收 一 连 串 的 
JSON 对 象 ， 这 些 JSON 对 象 记录 了 给 定 资源 类 别 内 所 有 资源 对 象 


的 变化 情况 。 

。 GET/watch/ 资 源 名 复数 格式 /<name>: 随时 间 变 化 ， 不 断 接收 一 连 
串 的 JSON 对 象 ， 这 些 JSON 对 象 记录 了 某 个 给 定 资源 对 象 的 变化 
情况 。 


上 述 接口 改变 了 返回 数据 的 基本 类 别 ，watch 动 词 返 回 的 是 一 连 串 
的 JSON 对 象 ， 而 不 是 单个 的 JSON 对 象 。 并 不 是 所 有 的 对 象 类 别 都 文 
持 “ 观 察 者 ”模式 的 API 接 口 ， 在 后 续 的 章节 中 将 会 说 明 哪 些 资源 对 象 文 
持 这 种 接口 。 


另外 ，Kubernetes 还 增加 了 HTTP Redirect HTTP Proxy 这 两 种 特 
殊 的 API 接 口 ， 前 者 实现 资源 重 定 加 访问， 后 者 则 实现 HTTP 请 求 的 代 
理 。 


4.2.4 API 应 说 明 


API Server 啊 应 用 户 请 求 时 附带 一 个 状态 码 ， 该 状态 码 符 合 HITP 
规范 。 表 4.1 列 出 了 API Server 可 能 返回 的 状态 码 。 


表 4.1 API Server 可 能 返回 的 状态 码 


表明 请 求 完全 成 功 

Created 表明 创建 类 的 请 求 完全 成 功 

NoContent 表明 请 求 完全 成 功 ， 同 时 HITP 响应 不 包含 响应 体 。 
在 响应 OPTIONS 方法 的 HTTP 请 求 时 返回 
TemporaryRedirect | 表明 请 求 资源 的 地 址 被 改变 ， 建 议 客户 端 使 用 Location 首部 给 出 的 临时 URL 来 定位 资源 
BadRequest 表明 请 求 是 非法 的 ， 建 议 客户 不 要 重 试 ， 修 改 该 请 求 

Unauthorized 表明 请 求 能 够 到 达 服 务 端 ， 且 服务 端 能 够 理解 用 户 请 求 ， 但 是 拒绝 做 更 多 的 事情 ， 
因为 客户 端 必 须 提 供认 证 信息 。 如 果 客 户 端 提供 了 认证 信息 ， 则 返回 该 状态 码 ， 表 
明 服 务 端 指出 所 提供 的 认证 信息 不 合适 或 非法 
Forbidden 表明 请 求 能 够 到 达 服务 端 ， 且 服务 端 能 够 理解 用 户 请 求 ， 但 是 拒绝 做 更 多 的 事情 ， 
因为 该 请 求 被 设置 成 拒绝 访问 。 建 议 客户 不 要 重 试 ， 修 改 该 请 求 

NotFound 表明 所 请 求 的 资源 不 存在 。 建 议 客户 不 要 重 试 ， 修 改 该 请 求 

MethodNotAllowed | 表明 请 求 中 带 有 该 资源 不 支持 的 方法 。 建 议 客户 不 要 重 试 ， 修 改 该 请 求 


编 B 描 R 
Conflict 表明 客户 端 尝试 创建 的 资源 已 经 存在 ， 或 者 由 于 冲突 请 求 的 更 新 操作 不 能 被 完成 
UnprocessableEntity | 表明 由 于 所 提供 的 作为 请 求 部 分 的 数据 非法 ， 创 建 或 修改 操作 不 能 被 完成 
TooManyRequests 表明 超出 了 客户 端 访问 频率 的 限制 或 者 服务 端 接收 到 多 于 它 能 处 理 的 请 求 。 建 议 客 
户 端 读 取 相应 的 Retry-After 首部 ， 然 后 等 待 该 首部 指出 的 时 间 后 再 重 试 
InternalServerEmor | 表明 服务 端 能 被 请 求 访 问 到 ， 但 是 不 能 理解 用 户 的 请 求 ， 或 者 服务 端 内 产生 非 预期 
中 的 一 个 错误 ， 而 且 该 错误 无 法 被 认 知 ; 或 者 服务 端 不 能 在 一 个 合理 的 时 间 内 完成 
处 理 〈 这 可 能 由 于 服务 器 临时 负载 过 重 造成 或 者 由 于 和 其 他 服务 器 通信 时 的 一 个 临 
时 通信 故障 造成 ) 
ServiceUnavailable | 表明 被 请 求 的 服务 无 效 。 建 议 客户 不 要 重 试 修改 该 请 求 
ServerTimeout 表明 请 求 在 给 定 的 时 间 内 无 法 完成 。 客 户 端 仅 在 为 请 求 指定 超时 (Timeout) 参数 时 


会 得 到 该 啊 应 


在 调用 API 接 口 发 生 错 误 时 ，Kubernetes 将 会 返回 一 个 状态 类 别 
(Status Kind) 。 下 面 是 两 种 常见 的 错误 场景 : 


(1) 当 一 个 操作 不 成 功 时 (例如 ， 当 服务 端 返回 一 个 非 2xx 
HTTP 状 态 码 时 ) 


(2) 当 一 个 HTTP DELETE 方 法 调用 失败 时 。 


状态 对 象 被 编码 成 JSON 格 式 ， 同 时 该 JSON 对 和 象 被 作为 请 求 的 响 
应 体 。 该 状态 对 象 包含 人 和 机 器 使 用 的 域 ， 这 些 域 中 包含 来 自 API 的 
关于 失败 原因 的 详细 信息 。 状 态 对 象 中 的 信息 补充 了 对 HTTP 状 态 码 的 
说 明 。 例 如 : 


$ curl -v -k -H "Authorization: Bearer 
WhCDvg4VPpYhrcfmF6ei7V9qlbqTubUc" 
HTTPs://10.240.122.184:443/api/v1/namespaces/default/pods/g 
rafana 
» GET /api/vi/namespaces/default/pods/grafana HTTP/1.1 
> User-Agent: curl/7.26.0 
> Host: 10.240.122.184 
> Accept: */* 
> Authorization: Bearer 
WhCDvg4VPpYhrcfmF6ei7V9qlbqTubUC 


> 


A 


HTTP/1.1 404 Not Found 
< Content-Type: application/json 
< Date: Wed, 20 May 2015 18:10:42 GMT 


< Content-Length: 232 


{ 
"kind": "Status", 
"apiVersion": "v1", 


"metadata": {}, 


"status": "Failure", 
"message": "pods \"grafana\"not found", 
"reason": "NotFound", 
"details": { 
"name": "grafana", 
"kind": "pods" 
3 
"code": 404 
} 


“status” 域 包含 两 个 可 能 的 值 :， Success 和 Failure ° 
“message” 域 包含 对 错误 的 可 读 摘 述 。 

“reason” 域 包含 说 明 该 操作 失败 原因 的 可 读 描述 。 如 有 果 该 域 的 值 为 
至， 则 表示 该 域内 没有 任何 说 明 信 息 。“reason” 域 澄清 HITP 状 态 
码 ， 但 没有 禾 盖 该 状态 码 。 

“details” 可 能 包含 和 “reason” 域 相关 的 扩展 数据 。 每 个 “reason” 域 可 
以 定义 它 的 扩展 的 “details” 域 。 该 域 是 可 选 的 ， 返 回 数据 的 格式 是 
不 确定 的 ， 不 同 的 reason 类 型 返回 的 “details” 域 的 内 容 不 一 样 。 


4.3 ”使 用 Java 程 序 访问 Kubernetes API 


本 介绍 如 何 使 用 Java 程 序 访 问 Kubernetes API。 在 Kubernetes 的 
官网 上 列 出 了 多 个 访问 Kubernetes API 的 开源 项 目 ， 其 中 有 两 个 是 用 
Java 语 言 开发 工具 的 开源 项 目 ， 一 个 是 OSGI， 男 一 个 是 Fabric8。 在 本 
廊 所 列 的 两 个 Java 开 发 例子 中 ， 一 个 是 基于 Jersey 的 ， 男 一 个 是 基于 
Fabric8 的 。 


4.3.1 Jersey 


Jersey 是 一 个 RESTful 请 求 服务 JAVA 框 架 。 与 Struts 类 似 ， 它 可 以 
FI Hibernate ^ Spring f£ Z8 3€ S » og E DNA A EJ R RESTful Web 
Service， 而 且 可 以 将 它 作为 客户 端 方 便 地 访问 RESTful Web Service fk 


如 果 没 有 一 个 好 的 工具 包 ， 则 开发 一 个 能 够 用 不 同 的 媒介 
(Media) 类 型 无 颖 地 暴露 你 的 数据 ， 以 及 很 好 地 抽象 客户 、 服 务 端 
通信 的 底层 通信 的 RESTful Web Services， 会 很 不 容易 。 为 了 能 够 简化 
用 Java 开 发 RESTful Web Service 及 其 客户 端的 流程 ， 业 界 设计 了 JAX- 
RS API » Jersey RESTful Web Services 框 架 是 一 个 开源 的 高 质量 的 框 
架 ， 它 为 用 JAVA 语言 开发 RESTful Web Service 及 其 客户 端 而 生 ， 支 持 
JAX-RS APIs。Jersey 不 仅 支 持 JAX-RS APIs， 而 且 在 此 基础 上 扩展 了 
API 接 口 ， 这 些 扩 展 更 加 方便 和 人 简化 了 RESTful Web Services 及 其 客户 
端的 开发 。 


由 于 Kuberetes API Server 是 RESTful Web Service， 因 此 此 处 选用 
Jersey 框 架 开 发 RESTful Web Service 客 户 端 ， 用 来 访问 Kubernetes 
API。 在 本 例 中 选用 的 Jersey 框 染 的 版 本 为 1.19， 所 涉及 的 Jar 包 如 图 4.6 
所 示 。 


|& | commons-codec-1.2 jar 2015/9/13 11:10 Executable Jar File 30 KB 
|& | commons-httpclient-3.1.jar 2015/9/13 11:09 Executable Jar File 298 KB 
要 | commons-logging-1.0.4.jar 2015/9/13 11:10 Executable Jar File 38 KB 
| & | jackson-core-asl-1.9.2. jar 2015/2/11 5:41 Executable Jar File 223 KB 
| & | jackson-jaxrs-1.9.2.jar 2015/2/11 5:41 Executable Jar File 18 KB 
|& | jackson-mapper-asl- 1.9.2 jar 2015/2/11 5:41 Executable Jar File 748 KB 
| &J jackson-xc- 1.9.2.jar 2015/2/11 5:41 Executable Jar File 21 KB 
lé] jersey-apache-client-1.19.jar 2015/2/11 5:41 Executable Jar File 22 KB 
&| jersey-atom-abdera-1.19.jar 2015/2/11 5:41 Executable Jar File 20 KB 
| & | jersey-client-1.19 jar 2015/2/11 5:41 Executable Jar File 131 KB 
| & | jersey-core-1.19.jar 2015/2/11 5:41 Executable Jar File 427 KB 
| & | jersey-guice-1.19 jar 2015/2/11 5:41 Executable Jar File 16 KB 
|S) jersey-json-1.19 jar 2015/2/11 5:41 Executable Jar File 162 KB 
|=} jersey-multipart-1.19 jar 2015/2/11 5:41 Executable Jar File 53 KB 
|| jersey-server-1.19.jar 2015/2/11 5:41 Executable Jar File 687 KB 
lé] jersey-servlet-1.19 jar 2015/2/11 5:41 Executable Jar File 126 KB 
lé] jersey-simple-server-1.19 jar 2015/2/11 5:41 Executable Jar File 12 KB 
lé] jersey-spring-1.19.jar 2015/2/11 5:41 Executable Jar File 18 KB 
(éj jettison-1.1 jar 2015/2/11 5:41 Executable Jar File 67 KB 
lé] jsr311-api-1.1.1 jar 2015/2/11 5:41 Executable Jar File 46 KB 
| | oauth-client-1.19jar 2015/2/11 5:41 Executable Jar File 15 KB 
|& | oauth-server-1.19.jar 2015/2/11 5:41 Executable Jar File 30 KB 
|&| oauth-signature-1.19 jar 2015/2/11 5:41 Executable Jar File 24 KB 


图 4.6 ”本 例 所 涉及 的 Jar 包 
对 Kubernetes API 的 访问 包含 如 下 三 个 方面 。 
(1) 指明 访问 资源 的 类 型 。 


(2) 访问 时 的 一 些 选项 (参数 ) ， 比 如 命名 空间 、 对 象 的 名 称 、 
过 滤 方 式 (标签 和 域 ; 、 子 目录 、 访 问 的 目标 是 否 是 代理 和 是 否 用 
watch 方 式 访问 等 。 


(3) 访问 的 方法 ， 比 如 增 、 删 、 改 、 查 。 


在 使 用 Jersey 框 架 访 问 Kubernetes API 之 前 ， 为 这 三 个 方面 定义 了 
三 个 对 象 。 第 1 个 定义 的 对 象 为 ResourceType， 它 定义 了 访问 资源 的 类 
型 ， 第 2 个 定义 的 对 象 是 Params， 它 定义 了 访问 API 时 的 一 些 选 项 ， 以 
及 通过 这 些 选 项 如 何 生 成 完整 的 URI; 第 3 个 定义 的 对 象 是 


RestfulClient ， 它 是 一 个 接口 ， 该 接口 定义 了 访问 API 的 方法 
(Method) 。 


ResourceType 是 一 个 ENUM 类 型 的 对 象 ， 定 义 了 16 种 资源 ， 代 码 
如 下 : 


package com.hp.k8s.apiclient.imp; 


publicenum ResourceType { 
NODES ("nodes"), 
NAMESPACES ( "namespaces"), 
SERVICES("services"), 
REPLICATIONCONTROLLERS("replicationcontrollers"), 
PODS("pods"), 
BINDINGS("bindings"), 
ENDPOINTS("endpoints"), 
SERVICEACCOUNTS("serviceaccounts"), 
SECRETS("secrets"), 
EVENTS("events"), 
COMPOMENTSTATUSES("componentstatuses"), 
LIMITRANGES("limitranges"), 
RESOURCEQUOTAS("resourcequotas"), 
PODTEMPLATES("podtemplates"), 

PERSISTENTVOLUMECLAIMS("persistentvolumeclaims"); 
PERSISTENTVOLUMES("persistentvolumes") ; 


private String type; 


private ResourceType(String type) { 


this.type = type; 


public String getType() { 


return type; 


Params 对 象 的 代码 如 下 : 


package com.hp.k8s.apiclient.imp; 


import java.io.UnsupportedEncodingException; 
import java.net.URLEncoder; 
import java.util.List; 


import java.util.Map; 


import org.apache.logging.1log4j.LogManager; 


import org.apache.logging.log4j.Logger; 


publicclass Params { 
privatestaticfinal Logger LOG 
LogManager .getLogger(Params.class.getName() ); 
private String namespace = null; 
private String name = null; 


private Map<String, String> fields = null; 


private Map<String, String> labels = null; 

private Map<String, String> notLabels = null; 

private Map<String, List<String>> inLabels = null; 

private Map<String, List<String>> notInLabels = 

null; 

private String json = null; 

private ResourceType resourceType = null; 

private String subPath = null; 

privateboolean isVisitProxy = false; 


privateboolean isSetWatcher = false; 


public String buildPath() { 
StringBuilder result = (isVisitProxy new 
StringBuilder ("/proxy") 
(isSetWatcher new 
StringBuilder("/watch") : new StringBuilder(""))); 


if (null !- namespace) 


result.append("/namespaces/").append(namespace); 


result.append("/").append(resourceType.getType( )); 
if (null !- name) 
result.append("/").append(name); 
if (null!=subPath) 


result.append("/").append(subPath); 


if (null != labels && !labels.isEmpty() || 
null != notLabels && !notLabels.isEmpty() 
|| null !- inLabels && 
inLabels.size() > 0 | | null ! = notInLabels && 
notInLabels.size() > 0 
|| null != fields && 


fields.size() > 0) ( 


StringBuilder labelSelectorStr 


null; 
StringBuilder fieldSelectorStr = 
null; 
try { 
labelSelectorStr = 
builderLabelSelector(); 
fieldSelectorStr - 
builderFiledSelector(); 
} catch 


(UnsupportedEncodingException e1) { 
LOG.error(e1); 


if (labelSelectorStr.length() + 
fieldSelectorStr.length() > 0) 
result.append(" "); 
if (labelSelectorStr.length() > 0) 


result.append("labelSelector=").append(labelSelectorStr.toS 


tring()); 


if 
(fieldSelectorStr.length() > 0) { 


result.append(","); 


if (fieldSelectorStr.length() > 0) 


result.append("fieldSelectorz").append(fieldSelectorStr.toS 


tring()); 


return result.toString(); 


private StringBuilder builderLabelSelector() throws 
UnsupportedEncodingException { 
StringBuilder result = new StringBuilder(); 
if (null != labels) { 
for (String key : labels.keySet()) 


if (result.length() > 0) ( 


result.append(","); 


result .append(URLEncoder . encode(key + i + 


labels.get(key), "GBK")); 
} 


if (null != notLabels) { 
for (String key : labels.keySet()) 


{ 
if (result.length() > 0) ( 
result.append(","); 
} 
result.append(URLEncoder.encode(key 十 "Iz" * 


labels.get(key), 
"GBK")); 


if (null != inLabels) { 
for (String key 
inLabels.keySet()) { 
if (result.length() > 0) { 


result .append(URLEncoder.encode(",","GBK")); 
} 


result.append(URLEncoder.encode(key 十 e in En 十 


listToString(inLabels.get(key), ",") + ")", "GBK")); 
} 


if (null != notInLabels) { 
for (String key 
inLabels.keySet()) { 


if (result.length() > 0) ( 


result .append(URLEncoder.encode(",","GBK")); 
} 


result .append(URLEncoder .encode(key 十 " notin (" + 


listToString(inLabels.get(key), ",") + ")", "GBK")); 
} 


LOG.info("label result:" + result); 


return result; 


private StringBuilder builderFiledSelector() throws 


UnsupportedEncodingException { 
StringBuilder result = new StringBuilder (); 
if (null != fields) { 
for (String key : fields.keySet()) 


{ 
if (result.length() > 0) ( 
result.append(","); 
j 
result.append(URLEncoder.encode(key + i + 


fields.get(key), "GBK")); 
} 


return result; 


private String listToString(List<String> list, 
String delim) { 
boolean isFirst = true; 
StringBuilder result = new StringBuilder (); 
for (String str : list) { 
if (isFirst) ( 
result.append(str); 
isFirst - false; 


) else ( 


result.append(delim).append(str); 
} 


return result.toString(); 


public String getNamespace() { 


return namespace; 


publicvoid setNamespace(String namespace) { 


this.namespace - namespace; 


public String getName() { 


return name; 


publicvoid setName(String name) { 


this.name - name; 


public Map<String, String» getFields() { 


return fields; 


publicvoid setFields(Map<String, String> fields) { 
this.fields = fields; 


public Map<String, String> getLabels() { 


return labels; 


publicvoid setLabels(Map<String, String> labels) { 
this.labels = labels; 


public String getJson() { 


return json; 


publicvoid setJson(String json) { 


this.json = json; 


public ResourceType getResourceType() { 


return resourceType; 


publicvoid  setResourceType(ResourceType 


resourceType) ( 


this.resourceType = resourceType; 


public String getSubPath() ( 


return subPath; 


publicvoid setSubPath(String subPath) ( 


this.subPath = subPath; 


publicboolean isVisitProxy() { 


return isVisitProxy; 


publicvoid setVisitProxy(boolean isVisitProxy) 


this.isVisitProxy = isVisitProxy; 


publicboolean isSetWatcher() { 


return isSetWwatcher; 


publicvoid setSetWatcher(boolean isSetWatcher) 


this.isSetWatcher = isSetWatcher; 


public Map<String, String> getNotLabels() { 


return notLabels; 


publicvoid setNotLabels(Map<String, String> 
notLabels) { 


this.notLabels = notLabels; 


public Map<String, List<String>> getInLabels() { 


return inLabels; 


publicvoid setInLabels(Map<String, List<String>> 
inLabels) { 


this.inLabels = inLabels; 


public Map<String, List<String>> getNotInLabels() { 


return notInLabels; 


publicvoid setNotInLabels(Map<String, List<String>> 
notInLabels) { 


this.notInLabels = notInLabels; 


Params 对 象 包 含 的 属性 说 明 如 表 4.2 所 示 。 
表 4.2 ”Params 对 象 包 含 的 属性 列表 


属 性 LAE: 


namespace Suing 类 型 属性 ， 指 明 资 源 所 在 的 命名 空间 ， 如 果 没 有 指定 该 值 ， 则 表明 访问 所 有 命名 空间 下 的 资源 对 象 


name Swing 类 型 属性 ， 在 访问 单个 资源 对 象 时 使 用 ， 如 果 没有 指定 该 值 ， 则 表明 访问 该 类 资源 列表 


fields Map<String, String> 类 型 属性 ， 通 过 资源 对 象 的 域 值 过 滤 访 问 结 果 


labels Map<String、Strine> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。 选 择 出 的 资源 对 象 包含 标签 列表 中 
所 列 的 标签 ( 即 Map 的 key) ， 且 所 选 资源 的 标签 的 value 和 标签 列表 中 的 value fif. (HI Map 的 value) 相等 


notLabels Map<Sting, Suing> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。 选 择 出 的 资源 对 象 包含 标签 列表 中 
所 列 的 标签 ( 即 Map 的 key)， 且 所 选 资源 的 标签 的 value 和 标签 列表 中 的 value fti (H! Map 的 value) 不 相等 


inLabels Map-String. List<String>> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。Map 对 和 象 的 key 值 为 标 
签名 称 ，Map 对 象 的 value 值 为 该 标签 可 能 包含 的 值 


notInLabels | Map-String. List<Strine>> 类 型 属性 ， 通 过 指定 的 标签 选择 器 列表 来 选择 资源 对 象 。Map 对 象 的 key 值 为 标签 
名 称 ，Map 对 象 的 value 值 为 列表 ， 表 明 资 源 对 象 包含 和 key 值 同 名 的 标签 ， 且 这 些 标签 的 值 不 在 该 列表 中 


json String 类 型 属性 ， 在 创建 或 修改 资源 对 象 时 使 用 ， 用 于 向 API Server 提供 资源 对 象 的 定义 


resourceType | ResourceType 类 型 属性 ， 用 于 指明 访问 资源 对 象 的 类 型 


subPath String 类 型 属性 ， 用 于 指明 访问 资源 的 子 目录 


isVisitProxy | Boolean 类 型 属性 ， 用 于 指明 是 否 通 过 Proxy 的 方式 访问 资源 对 象 


isSetWatcher | Boolean 类 型 属性 ， 表 明 是 否 通过 Watcher 方式 访问 资源 对 象 


Params 的 buildPath 方 法 用 于 构建 访问 URL 的 完整 路 径 。 


接口 对 象 RestfulClient 定 义 了 访问 API 接 口 的 所 有 方法 


(Method) ， 其 代码 列表 如 下 : 


package com.hp.k8s.apiclient; 


import com.hp.k8s.apiclient.imp.Params; 


publicinterface RestfulClient { 


INR 


public String get(Params params); // 获 得 单个 资 


public String list(Params params); // 获 得 资源 对 象 列表 


public String create(Params params); // 创 建 资源 对 象 


public String delete(Params params); // 删 除 某 个 资源 对 
E 


public String update(Params params); // 部 分 更 新 某 个 资 


源 对 象 
public String updatewithMediaType(Params 


params,String mediaType); // 通 过 mediaType， 实 现 Merge 


public String replace(Params params);  //TH& 


对 象 
public String options(Params params); 


public String head(Params params); 


其 中 get 和 1list 方 法 对 应 Kubernetes API 的 GET 方 法 ; create 方 法 对 应 
API 中 的 POST 方 法 ; delete 方法 对 应 API 中 的 DELETE 方 法 ，update 方 法 
对 应 API 中 的 PATCH 方法 ;replace 方法 对 应 API 中 的 PUT 方法 ;options 
方法 对 应 API 中 的 OPTIONS 方 法 ，head 方 法 对 应 API 中 的 HEAD 方 法 。 


该 接口 的 基于 Jersey 框 架 的 实现 类 如 下 所 示 : 


package com.hp.k8s.apiclient.imp; 
import javax.ws.rs.core.MediaType; 


import org.apache.logging.log4j.LogManager ; 


import org.apache.logging.log4j.Logger; 


import com.hp.k8s.apiclient.RestfulClient; 
import com.sun.jersey.api.client.Client; 
import com.sun.jersey.api.client.WebResource; 
import 
com.sun.jersey.api.client.config.DefaultClientConfig; 
import 
com.sun.jersey.client.urlconnection.URLConnectionClientHand 


ler; 


publicclass JerseyRestfulClient implements 
RestfulClient ( 
privatestaticfinal Logger LOG = 
LogManager.getLogger(RestfulClient. class.getName()); 


privatestaticfinal String METHOD PATCH - "PATCH"; 


private String _baseUrl = null; 


Client client = null; 


public JerseyRestfulClient(String baseUrl) { 
DefaultClientConfig config - new 


DefaultClientConfig(); 


config.getProperties().put(URLConnectionClientHandler.PROPE 
RTY HTTP | URL CONNECTION SET METHOD WORKAROUND, true); 


client = Client.create(config); 


this. baseUrl = baseUrl; 


@Override 


public String get(Params params) { 


WebResource resource 


_client.resource(_baseUrl + params.buildPath()); 


String response 
resource.accept(MediaType.APPLICATION JSON TYPE). 
get(String.class); 


LOG.info("Get one resource:\n" + response); 


return response; 


@Override 
public String list(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 
LOG.info("URL:" +  baseUrl + 
params.buildPath()); 
String response = 
resource.accept (MediaType.APPLICATION_JSON_TYPE). 


get(String.class); 


return response; 


@Override 
public String create(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 
LOG.info("URL:" + _baseUrl + 
params.buildPath()); 
LOG.info("Create resource:" + 
params.getJson()); 
String response - (null -- 


params.getJson()) 


resource.accept(MediaType.APPLICATION JSON).post(String.cla 


ss) 


resource. type(MediaType.APPLICATION_JSON) .accept (MediaType. 


APPLICATION JSON).post(String.class, 


params.getJson()); 


return response; 


@Override 
public String delete(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 


String response = 


resource.accept(MediaType.APPLICATION JSON TYPE). 
delete(String.class); 

LOG.info("Detelet resource " + 
params.getResourceType().getType() + "/" + params.getName() 
+ " result:^n" 


* response); 


return response; 


@Override 
public String update(Params params) { 
return updatewithMediaType(params, 


MediaType.APPLICATION_JSON); 
} 


@Override 
public String updateWithMediaType(Params params, 
String mediaType) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 
LOG.info("URL:" + _baseUrl + 
params.buildPath()); 
LOG.info("Patch resource:" + 
params.getJson()); 
String response = 


resource.type(mediaType).accept(MediaType.APPLICATION 


JSON TYPE).method(METHOD PATCH, String.class, 
params.getJson()); 
LOG.info("Update resource " + 


params.buildPath() + " result:\n" + response); 


return response; 


@Override 
public String replace(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 
LOG.info("URL:" + _baseUrl + 
params.buildPath()); 
LOG.info("Replace resource:" + 
params.getJson()); 

String response = 
resource. type(MediaType.APPLICATION_JSON_TYPE).accept 
(MediaType.APPLICATION_JSON_TYPE) 

.put(String.class, 
params.getJson()); 
LOG.info("Replace resource " + 


params.buildPath() + " result:\n" + response); 


return response; 


@Override 
public String options(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 

String response = 
resource. type(MediaType.APPLICATION_JSON_TYPE).accept 
(MediaType.TEXT. PLAIN TYPE) 

.options(String.class); 
LOG.info("Get options for resource " + 
params.getResourceType(). getType() + a 十 
params.getName( ) 


+ " result:\n" + response); 


return response; 


@Override 
public String head(Params params) { 
WebResource resource = 
_client.resource(_baseUrl + params.buildPath()); 

String response = 
resource.accept (MediaType. TEXT_PLAIN_TYPE).head(). 
getResponseStatus().toString(); 

LOG.info("Get head for resource " + 
params.getResourceType().getType() + "/" + params.getName() 
+ " result:\n" 


+ response); 


return response; 


@Override 
publicvoid close() { 


_client.destroy(); 


该 对 象 中 包含 如 下 代码 : 


config.getProperties().put(URLConnectionClientHandler.PROPE 
RTY HTTP URL. CONNECTION SET METHOD WORKAROUND, true); 


该 段 代 码 的 作用 是 使 Jersey 客 户 端 能 够 文 持 除 标准 REST 方 法 外 的 
方法 ， 比 如 PATCH 方法 。 该 段 代 人 码 能 访问 除 watcher 外 的 所 有 
Kubernetes API 接 口 ， 在 后 续 的 章节 中 我 们 会 举例 说 明 如 何 访问 
Kubernetes API ° 


4.3.2  Fabric8 


Fabrics £2 E 4 KILER, Kubernetes Client 只 是 其 中 之 一 ， 也 是 
Kubernetes 官 网 中 提 到 的 Java Client API 之 一 。 本 例子 代码 涉及 的 Jar 包 
如 图 4.7 所 示 。 


HH e 


因为 该 工具 包 


l| dnsjava-2.1.7.jar 2015/8/31 14:23 Executable Jar File 301 KB 
(=) fabric8-utils-2.2.22 jar 2015/8/31 14:23 Executable Jar File 134 KB 
lė] jackson-annotations-2.6.0 jar 2015/8/31 16:27 Executable Jar File 46 KB 
|= | jackson-core-2.6.1 jar 2015/8/31 16:28 Executable Jar File 253 KB 
lė] jackson-databind-2.6.1 jar 2015/8/31 15:56 Executable Jar File 1,140 KB 
|S) jackson-dataformat-yaml-2.6.1 jar 2015/8/31 15:5€ Executable Jar File 313 KB 
|=) jackson-module-jaxb-annotations-2.6.0.jar 2015/8/31 16:24 Executable Jar File 32 KB 
|S) json-20141113 jar 2015/8/31 14:23 Executable Jar File 64 KB 
|=) kubernetes-api-2.2.22 jar 2015/8/31 14:22 Executable Jar File 72 KB 
lj kubernetes-client-1.3.8jar 2015/8/31 15:37 Executable Jar File 2,262 KB 
|=) kubernetes-model-1.0.12.jar 2015/8/31 15:56 Executable Jar File 2,308 KB 
|&|log4j-api-2.3.jar 2015/8/31 16:18 Executable Jar File 133 KB 
|S) log4j-core-2.3 jar 2015/8/31 15:56 Executable Jar File 808 KB 
|S) log4j-slf4j-impl-2.3.jar 2015/8/31 15:56 Executable Jar File 23 KB 
l| oauth-20100527 jar 2015/8/31 15:56 Executable Jar File 44 KB 
|S) openshift-client-1.3.2 jar 2015/8/31 14:23 Executable Jar File 24 KB 
|=) slf4j-api-1.7.12jar 2015/8/31 15:56 Executable Jar File 32 KB 
|=) sundr-annotations-0.0.25 jar 2015/8/31 15:56 Executable Jar File 146 KB 
|&| validation-api-1.1.0.Final.jar 2015/8/31 14:23 Executable Jar File 63 KB 


图 4.7 例子 代码 涉及 的 Jar 包 


M 


已 经 对 访问 Kubernetes API 客 户 端 做 了 较 好 的 封装 ， 
因此 其 访问 代码 比较 简单 ， 其 具体 的 访问 过 程 会 在 后 续 的 章节 举例 芒 


Fabric 8 的 Kubernetes API 客 户 端 工 具 包 只 能 访问 Node、Service、 
Pod ^ Endpoints ^ Events ^ Namespace ^ PersistenetVolumeclaims ^ 


PersistenetVolume ^ ReplicationController ^ ResourceQuota ^ Secret 和 


ServiceAccount 这 几 个 资源 类 型 ， 不 能 使 用 OPTIONS 和 HEAD 方 法 访问 
资源 ， 且 不 能 以 代理 方式 访问 资源 ， 但 其 对 以 watcher 方 式 访问 资源 做 
了 很 好 的 支持 。 


4.3.3 ”使 用 说 明 


首先 ， 举 例 说 明 对 API 资 源 的 基本 访问 ， 也 束 是 对 资源 的 增 、 
删 、 改 、 查 ， 以 及 替换 资源 的 status。 其 中 会 单独 对 Node 和 Pod 的 特殊 
接口 做 举例 说 明 。 表 4.3 列 出 了 各 资源 对 象 的 基本 API 接 口 。 


表 4.3 各 资源 对 象 的 基本 API 接 口 


资 源 类 型 5 i URL Path 说 0H 备 注 
GET api/vl/nodes 获取 Node 列表 
EE 


G /api/vl/nodes/ {name} 获取 一 个 Node WH 
PATCH /api/v1/nodes/ {name} 部 分 更 新 一 个 Node WR 
PUT /api/v1/nodes/{name} 替换 一 个 Node HS 


FR Nama WR 


/api/vi/namespaces 创建 一 个 Namespace X1 $: 


/api/v1/namespaces/ {name} 删除 一 个 Namespace X1 $e 


/api/v1/namespaces/ {name} 获取 一 个 Namespace X1 $. 
/api/v1/namespaces/ (name) 部 分 更 新 一 个 Namespace 31 $. 
ares 
替换 一 个 Namespace 对 象 的 最 终 方 | f Fabrics 中 没有 
££ Fabrics 中 没有 


/api/vl/services 获取 Service 列表 


/api/vl/services 创建 一 个 Service HH 


NAMESPACES 


/api/vl/namespaces/ {name}/finalize 


/api/v1/namespaces/{name}/status | 替换 一 个 Namespace 对 象 的 状态 


/api/v1/namespaces/{namespace}/se | 获取 某 个 Namespace 下 的 Service 列 
tvices # 

-— (namespace /se 在 某 个 Namespace 下 创建 列表 

tvices 

/api/v1/namespaces/{namespace}/se | 删除 菜 个 Namespace 下 的 
rvices/ (name? Service 对 象 


/api/v1/namespaces/{namespace}/se | 7k IK X: 4+ Namespace 下 的 


tvices/ {name} Service 3j] $ 
/api/vl/namespaces/(namespace]/se | 部 分 更 新 某 个 Namespace 下 的 
rvices/ {name} Service 3j $ 


/api/v1/namespaces/{namespace}/se | 14 换 菜 个 Namespace 下 的 


rvices/ (name) Service 对 象 


资源 类 型 


GET 

POST 
REPLICATIONC 
ONTROLLERS 

GET 

PUT 


GET 获取 一 个 Pod 列表 


TT EP 一 


过 


o 
m 
区 
Iu] 


法 URLPath 
PRC 列表 
创建 一 个 RC 对 多 


lapivl/ / {namespace} / 
"— Eu 人 
plicationcontrollers 
/api'vl/namespaces/(namespace]/re | 在 某 个 Namespace 下 创建 一 个 RC 
plicationcontrollers We 
/apvv1 /names / {namespace} / 
uA . — — Bie X Namespace 下 的 RC WHR 
plicationcontrollers/ {name} 
icd : — ic dk IE Namespace 下 的 RC WHR 
plicationcontrollers/ {name} 
/api/vl/namespaces/(namespace]/re | 部 分 更 新 某 个 Namespace 下 的 RC 
plicationcontrollers/ {name} 对 象 


Ju 


/api'vl/names; J (namespace) / 
ver nora TSEN 
plicationcontrollers/ {name} 


GET /api/vl/namespaces/ {namespace} ‘pods | 获取 某 个 Namespace 下 的 Pod 5/3 


续 表 
注 
{EM Namespace 下 创建 一 个 Pod 
删除 某 个 Namespace 下 的 一 个 Pod 
ds/{name} WR 
aii 
ds/{name} WR 
ds/ {name} Pod 对 象 
ds/ {name} 象 
/api'vl/namezpaces/ {namespace}/po 在 Fabricg 中 没有 
ds/{name}/status BRA 实现 
ds/{name}/binding $ Binding 实现 
ds/(name]/exec 对 象 ， 并 执行 exec 实现 
— 080 
ds/ {mame} /exec WR, FAT exec 实现 


$ EIS S 


资 源 类 型 


BINDINGS 


SERVICEACCOU 
NTS 


续 表 
[A 法 | urpean | ama | 备注 | 


ds/{name}/log 对 象 ， 并 获取 log 日 志 信 息 实现 
ds/{name}/portforward 对 象 ， 并 实现 端口 转发 实现 
ds/ (name) /portforward 对 象 ， 并 实现 端口 转发 实现 

[post |/api'vibindines | NAR Binding | 


POST /api/vl/namespaces/(namespace]/bi | 在 X: 个 Namespace 下 创建 一 个 
ndings Binding 对 象 


ik Endpoint 列表 | 
[POST — |/spivilendpoins | 创建 ~ 个 Endpoint 对 多 | 


J 
dpoints 对 象 列表 
/api/vl/namespaces/(namespace]/en| 在 X: 个 Namespace 下 创建 一 个 a 
dpoints Endpoint 对 象 
pem reas cama =| RN 
"^ ee a 5 — 1 5551 
dpoints/ {name} 对 象 
dpoints/ {name} Endpoint 对 象 
points! {name} 对 象 


itt Seviceaccount 列表 
创建 一 个 Serviceaccount 1L 


rviceaccounts Serviceaccount 对 象 列 表 
/api/vl/namespaces/ [namespace] /se | 在 某 个 Namespace 下 创建 一 个 
rviceaccounts Serviceaccount 对 象 


/api'v1 /mamespaces/{namespace}/se | MIIA Namespace 下 的 一 个 
rviceaccounts/ {name} Serviceaccount 对 象 
/api/v1 /mamespaces/{namespace}/se | 获取 某 个 Namespace 下 的 一 个 


GET 
rviceaccounts/ {name} Serviceaccount 对 象 


续 表 
资源 类 型 | 方 法 | uray | ana | 各 注 | 


fapi/vl /namespaces/ {namespace} /se | 部 分 更 新 某 个 Namespace 下 的 一 个 
rviceaccounts/ {name} Serviceaccount 对 象 
ces! {i 


PATCH 
— /api/vl/namespaces/ (namespace]/se | HEWA Namespace 下 的 一 个 
rviceaccounts/ {name} Serviceaccount 对 象 


COMPONENT 
ATUSES 


fapi/vi/secrets 获取 Secret 列表 | d 
POST /api/vl/secrets 创建 一 个 Secret 3] FE. — 1 


— — | 
(api/v1 /mamespaces/{namespace}/se | 在 某 个 Namespace 下 创建 一 个 Secret 
POST 
crets WR 
fapi'v1/ / f TN: TRF 
berie api/vl/namespaces/ {namespace} /se | 删除 菜 个 Namespace 下 的 一 个 Secret 
cretz/ (name 对 象 
CER /api/vl/namespaces/ {namespace} /se | 获取 某 个 Namespace 下 的 一 个 Secret 
crets/ {name} WR 
fapi/v1 /mamespaces/{namespace}/se | 部 分 更 新 某 个 Namespace 下 的 一 个 
crets/{name} Secret 3| 
vor /api/vl /namespaces/ {namespace} /se | HRA Namespace 下 的 一 个 Secret 
cretz/ (name) 对 象 


iki Event 列表 | 
创建 一 个 Event ui | ] 


a 
ents 对 象 
/api/vl mamespaces/ {namespace} /ev | 删除 菜 个 Namespace 下 的 一 个 Event 
sa 
/apivl mamespaces/{namespace}/ev | 获取 某 个 Namespace 下 的 一 个 Event 


/api/vl/namespaces/ (namespace]/ev | 部 分 更 新 某 个 Namespace 下 的 一 个 
ents/ {name} Event 3] $. 


fapivl /namespaces/ (namespace) /ev | 4% 4+ Namespace 下 的 一 个 Event 
ents/ {name} WR 


PUT 


T | — | 


ST 
—_ /api/vl mamespaces/{namespace}/co | 获取 某 个 Namespace 下 的 Component 
mponentstatuses Status 列表 


资源 类 型 法 
ime /api/'vl/namespaces/ {namespace} /co | 获取 某 个 Namespace 下 的 一 个 
tuses/ {name} ComponentStatus 1| € 


GET ikl LimitRange 列表 —, 
post | /apivifimitanges | fit LimitRange 对象 | 


i 
mitranges 列表 
| 
post | mitranges LimitRange 对 象 

/api'v1/mamespaces/{namespace}/li | 234+ Namespace 下 的 一 个 
| 

mitranges/ {name} LimitRange 3| $. 

/api/vl/namespaces/(namespace]/li | 部 分 更 新 某 个 Namespace 下 的 一 个 NEN 
ee | 
meli 

mitranges/ {name} LimitRange 3] $ 


jk ResourceQuota 列表 a 
创建 ~ 个 ResourceQaoa 对 象 |_| 


EA | 
sourcequotas Quota 列表 
| — 
sourcequotas Resource Quota 对 象 
RESOURCEQUO sourcequotas/ {name} Resource Quota 对 象 
sourcequotas/ {name} Resource Quota 对 你 
ei ues 
/api'vl/namespaces/ {namespace} /re 
Resource Quota 对 象 
sourcequotas/ (name) /status Resource Quota 对 象 状态 实现 


续 表 
|GET |iapiviipodtemplates | le PodTemplate E | 
[post | /apivLfpodtemplates | lat“ PoaTemplatet | | 


dtemplates PodTemplate 列表 
dtemplates PodTemplate 对 象 
dtemplates/ {name} PodTemplate 对 象 
dtemplates/ {name} PodTemplate 对 象 
fapi/vl/namespaces/ (namespace) /po | 部 分 更 新 某 个 Namespace 下 的 一 个 E 3 
dtemplates/(name] PodTemplate 对 象 
/api/vl/namespaces/ {namespace} /po | HHS IA Namespace 下 的 一 个 L 3 
dtemplates/(name] PodTemplate 对 象 


[cer __[/apivtipersictentvolumes | #6 PersistentVolume ik | | 
Serr 
删除 一 个 PersistentVolume 3} $ 

PERSISTENTVO |GET | 获取 一 个 PersictentVolume 对 条 

i i 
[pur [apifvt/persistentvolumes/(name) tH —4 PeisenVolme ai | | 


GET 获取 PersistentVolumeClaim 列表 
Unt tectam 人 
获取 某 个 Namespace 下 的 Persistent 
VolumeClaim 列表 
在 某 个 Namespace 下 创建 一 个 
Persistent VolumeClaim 对 象 


/api'v1 /mamespaces/{namespace}/pe | HIENA Namespace 下 的 一 个 
rsistentvolumeclaims/ {name} Persistent VolumeClaim 对 象 
/api'vl/namespaces/ {namespace} /pe | 获取 某 个 Namespace 下 的 一 个 
rsistentvolumeclaims/ {name} Persistent VolumeClaim 对 象 
/api'v] /mamespaces/{namespace}/pe | 部 分 更 新 某 个 Namespace 下 的 一 
rsistentvolumeclaims/ {name} 个 Persistent VolumeClaim 对 象 


URL Path 说 明 


/api/v1/namespaces/ {namespace} /pe | 替换 某 个 Namespace 下 的 一 个 


rsistentvolumeclaims/ {name} Persistent VolumeClaim 对 象 
/api/v1/namespaces/ {namespace} /pe | 替换 某 个 Namespace 下 的 一 个 在 Fabric8 中 没有 


rsistentvolumeclaims/{name}/status | Persistent VolumeClaim 对 象 状态 实现 


首先 ， 举 例 说 明 如 何 通过 API 接 口 来 创建 资源 对 象 。 我 们 需要 创 
建 访问 API Server 的 客户 问 ， 基 于 Jersey 框 架 的 代码 如 下 : 


RestfulClient _restfulClient = new 


JerseyRestfulClient("http://192.168.1.128:8080/api/v1"); 


其 中 | http//192.168.1.128: 8080 7j API Server 的 地 址 。 基 于 
Fabric8 框 架 的 代码 如 下 : 


Config _conf = new Config(); 
KubernetesClient_kube = new 


DefaultKubernetesClient("http://192.168.1.128: 8080"); 


分 别 通过 上 面 的 两 个 客户 端 创建 Namespace 资 源 对 象 ， 基 于 Jersey 
框架 的 代码 如 下 : 


privatevoid testCreateNamespace() { 


Params params = new Params(); 
params.setResourceType(ResourceType.NAMESPACES) ; 
params.setJson(Utils.getJson("namespace.json")); 


LOG.info("Result:" + 


_restfulClient.create(params) ); 


j 


Hr, “namespace.json” 7j fi!) & Namespace HA VT RAISON E X. , 
代码 如 下 : 


{ 
"kind":"Namespace", 
"apiVersion": "vi", 
"metadata": { 


"name": "ns-sample" 


j 


基于 Fabric8 框 架 的 代码 如 下 : 


privatevoid testCreateNamespace() { 
Namespace ns = new Namespace(); 
ns.setApiVersion(ApiVersion.V 1); 
ns.setKind("Namespace"); 
ObjectMeta om = new ObjectMeta(); 
om.setName("ns-fabric8"); 


ns.setMetadata(0om); 


_kube.namespaces().create(ns); 


LOG.info( kube.namespaces().list().getItems().size()); 
} 


由 于 Fabric8 框 架 对 Kubernetes API 对 象 做 了 很 好 的 封装 ， 对 其 中 的 
大 量 对 象 都 做 了 定义 ， 所 以 用 户 可 以 通过 其 提供 的 资源 对 象 去 定义 
Kubernetes API 对 象 ， 例 如 上 面 例 子 中 的 Namespace 对 象 。Fabric8 框 架 


中 的 kubernetes-model 工 具 包 用 于 API 对 象 的 封装 。 在 上 面 的 例子 中 ， 
通过 Fabric8 框 架 提 供 的 类 创建 了 一 个 名 为 “ns-fabric8” 的 命名 空间 对 
象 。 


接 下 来 我 们 会 通过 基于 Jeysey 框 架 的 代码 去 创建 两 个 Pod 资 源 对 
象 。 在 两 个 例子 中 ， 一 个 是 在 上 面 创建 的 “ns-sample”Namespace 中 创 
建 Pod 资 源 对 象 ， 男 一 个 是 为 后 续 创建 “cluster service” 而 创建 的 Pod 资 
源 对 象 。 由 于 基于 Fabric8 框 加 创建 Pod 资 源 对 象 的 方法 很 简单 ， 因 此 
不 再 用 Fabric8 框 架 对 上 壕 两 个 例子 做 说 明 。 通 过 基于 Jersey 框 染 创 建 
这 两 个 Pod 资 源 对 象 的 代码 如 下 : 


privatevoid testCreatePod() { 
Params params = new Params(); 


params.setResourceType(ResourceType.PODS) ; 


params.setJson(Utils.getJson("podInNs.json")); 
params.setNamespace("ns-sample"); 
LOG.info("Result:" + 


_restfulClient.create(params) ); 


params.setJson(Utils.getJson("pod4ClusterService.json")); 
LOG.info("Result:" 十 
_restfulClient.create(params) ); 


j 


其 中 ，podInNs.json 和 pod4ClusterService.json 是 创建 两 个 Pod 资 源 
对 象 的 定义 。podInNs.json 文 件 的 内 容 如 下 : 


{ 

"kind":"Pod", 
"apiVersion":"v1", 
"metadata": { 


"name":"pod-sample-in-namespace", 


"namespace": "ns-sample" 
ty 
"spec": { 


"containers": [{ 
"name":"mycontainer", 
"image": "kubeguide/redis-master" 


}] 


pod4ClusterService.json 文 件 的 内 容 如 下 : 


{ 
"kind":"Pod", 
"apiVersion":"v1", 
"metadata": { 
"name":"pod-sample-4-cluster-service", 
"namespace": "ns-sample", 


"labels": { 


"k8s-cs": "kube-cluster-service", 


"k8s-test": "kube-cluster-test", 
"k8s-sample-app": "kube-service-sample", 
"kkk": "bbb" 

} 

3 

"spec": { 


"containers": [{ 
"name":"mycontainer", 
"image": "kubeguide/redis-master" 


}] 


下 面 的 例子 代码 用 于 获取 Pod 资 源 列表 ， 其 中 第 1 部 分 代码 用 于 获 
取 所 有 的 Pod 资 源 对 象 ， 第 2、3 部 分 代码 主要 是 列举 如 何 使 用 标签 这 
择 Pod 资 源 对 象 ， 最 后 一 部 分 代码 用 于 举例 说 明 如 何 使 用 field 选 择 Pod 
资源 对 象 。 代 码 如 下 : 


privatevoid testGetPodList() { 
Params params = new Params(); 
params.setResourceType(ResourceType.PODS); 
LOG.info("Result:" + 


_restfulClient.list(params) ); 


Map<String, String> labels = new 


HashMap<String, String>(); 


labels.put("k8s-cs", "kube-cluster- 
service"); 
labels.put("k8s-sample-app", "kube-service- 
sample"); 
params.setLabels(labels); 
LOG.info("Result:" + 
_restfulClient.list(params) ); 


params.setLabels(null); 


Map<String, List<String>> inLabels = new 
HashMap<String, List<String>>(); 
List list = new ArrayList<String>(); 
list.add("kube-cluster-service"); 
list.add("kube-cluster"); 
inLabels.put("k8s-cs", list); 
params.setInLabels(inLabels) ; 
LOG.info("Result:" 十 
_restfulClient.list(params) ); 


params.setInLabels(null) ; 


Map<String, String> fields = new 
HashMap<String, String>(); 
fields.put("metadata.name", "pod-sample-4- 
cluster-service"); 
params.setNamespace("ns-sample"); 
params.setFields(fields); 


LOG.info("Result:" 十 


_restfulClient.list(params)); 
j 


接 下 来 的 例子 代码 用 于 替换 一 个 Pod 对 象 ， 在 通过 Kubernetes API 
替换 一 个 Pod 资 源 对 象 时 需要 注意 两 点 : 


(1) 在 替换 该 资源 对 象 前 ， 先 从 API 中 获取 该 资源 对 象 的 JSON 对 
象 ， 然 后 在 该 JSON 对 象 的 基础 上 修改 需要 替换 的 部 分 ; 


(2) 在 Kubernetes API 提 供 的 接口 中 ，PUT 方 法 (replace) Ax 
持 替 换 容器 的 image 部 分 


代码 如 下 : 


privatevoid testReplacePod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 


params.setName("pod-sample-in-namespace"); 


params.setJson(Utils.getJson("pod4Replace.json")); 


params.setResourceType(ResourceType.PODS); 


LOG.info("Result:" + 
restfulClient.replace(params)); 


j 


其 中 ，pod4Replace.json 的 内 容 如 下 : 


{ 
"kind": "Pod", 
"apiVersion": "v1", 


"metadata": { 


"name": "pod-sample-in-namespace", 
"namespace": "ns-sample", 
"selfLink": "/api/vi/namespaces/ns-sample/pods/pod- 


sample-in-namespace", 
"uid": "084ff63e-59d3-11e5-8035-000c2921ba71", 
"resourceVersion": "45450", 
"creationTimestamp": "2015-09-13T04:51:01Z" 
ty 
"spec": { 
"volumes": [ 
{ 
"name": "default-token-szoje", 
"secret": { 


"secretName": "default-token-szoje" 


j 


]; 


"containers": [ 
"name": "mycontainer", 
"image": "centos", 


"resources": (Jj, 


"volumeMounts": [ 


{ 


"name": "default-token-szoje", 


"readOnly": true, 


"mountPath": 
"/var/run/secrets/kubernetes.io/serviceaccount" 
} 
], 
"terminationMessagePath": "/dev/termination-log", 


"imagePullPolicy": "IfNotPresent" 


j 
]; 


"restartPolicy": "Always", 
"dnsPolicy": "ClusterFirst", 
"serviceAccountName": "default", 
"serviceAccount": "default", 
"nodeName": "192.168.1.129" 
ty 

"status": { 
"phase": "Running", 
"Conditions": [ 

{ 
"type": "Ready", 
"status": "True" 

} 


], 
"hostIP": "192.168.1.129", 


"podIP": "10.1.10.66", 
"startTime": "2015-09-11T15:17:28Z", 
"containerStatuses": [ 
{ 

"name": "mycontainer", 
"state": { 
"running": { 
"startedAt": "2015-09-11T15:17:30Z" 

} 

ty 

"lastState": {}, 
"ready": true, 
"restartCount": 0, 
"image": "kubeguide/redis-master", 

"imageID": 
"docker://5630952871a38cddffda9ec611f5978ab0933628fcd54cd7d 
7677ce6b17de33Ff", 

"containerID": 
"docker://7bf0d454c367418348711556e667fd1ef6a04d7153d 


24bfcac2e2e06da634a9f" 
} 


Be BEE PN PPP SH T 4.2.4 fe BI BN Merge AIt: Merge 
Patch#ll Strategic Merge Patch ° 


第 1 种 Merge 方 式 的 示例 如 下 : 


privatevoid testUpdatePod1() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 


params.setName("pod-sample-in-namespace"); 


params.setJson(Utils.getJson("pod4MergeJsonPatch.json")); 


params.setResourceType(ResourceType.PODS); 


LOG.info("Result:" 十 
_restfulClient.updatewithMediaType(params, "application/ 
merge-patch+json")); 


其 中 ，pod4MergeJsonPatch.json 的 内 容 如 下 : 


{ 
"metadata": { 
"labels": { 
"k8s-cs": "kube-cluster-service", 
"k8s-test": "kube-cluster-test", 
"k8s-sa5555mple-app": "kube-service-sample", 


"kkk": "bbb4444" 
j 


第 2 种 Merge 方 式 (Strategic Merge Patch) 的 示例 如 下 : 


privatevoid testUpdatePod2() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 


params.setName("pod-sample-in-namespace"); 


params.setJson(Utils.getJson("pod4StrategicMerge.json")); 


params.setResourceType(ResourceType.PODS); 


LOG.info("Result:" 十 
_restfulClient.updatewithMediaType(params, 


"application/strategic-merge-patch+json") ); 


j 
其 中 ，pod4StrategicMerge.json 的 内 容 如 下 : 


{ 

"spec": { 

"containers": [{ 
"name":"mycontainer", 
"image":"centos", 
"patchStrategy":" merge", 


"patchMergeKey" : "name" 


}] 


接 下 来 实现 了 修改 Pod 资 源 对 象 的 状态 ， 代 码 如 下 : 


privatevoid testStatusPod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 


params.setSubPath("/status"); 


params.setJson(Utils.getJson("pod4Status.json")); 


params.setResourceType(ResourceType.PODS); 


.restfulClient.replace(params); 


其 中 ，pod4Status.json 的 内 容 如 下 : 


{ 
"kind": "Pod", 
"apiVersion": "vi", 


"metadata": ( 


"name": "pod-sample-in-namespace", 
"namespace": "ns-sample", 
"selfLink": "/api/vi/namespaces/ns-sample/pods/pod- 


sample-in-namespace", 
"uid": "adid803f-59ec-11e5-8035-000c2921ba71", 
"resourceVersion": "51640", 


"creationTimestamp": "2015-09-13T07:54:35Z" 


3 
"spec": ( 
"volumes": [ 
{ 
"name": "default-token-szoje", 
"secret": { 


"secretName": "default-token-szoje" 


j 


]; 


"containers": [ 

{ 
"name": "mycontainer", 
"image": "kubeguide/redis-master", 
"resources": {}, 
"volumeMounts": [ 

{ 

"name": "default-token-szoje", 


"readOnly": true, 


"mountPath": 
"/var/run/secrets/kubernetes.io/serviceaccount" 
} 
], 
"terminationMessagePath": "/dev/termination-log", 


"imagePullPolicy": "IfNotPresent" 


j 
]; 


"restartPolicy": "Always", 
"dnsPolicy": "ClusterFirst", 
"serviceAccountName": "default", 
"serviceAccount": "default", 
"nodeName": "192.168.1.129" 
ty 

"status": { 
"phase": "Unknown", 
"conditions": [ 

{ 
"type": "Ready", 
"status": "false" 

} 


], 
"hostIP": "192.168.1.129", 


"podIP": "10.1.10.79", 
"startTime": "2015-09-11T18:21:02Z", 
"containerStatuses": [ 
{ 
"name": "mycontainer", 
"state": { 
"running": { 
"startedAt": "2015-09-11T18:21:03Z" 
} 


ty 
"lastState": {}, 


"ready": true, 


"restartCount": 0, 
"image": "kubeguide/redis-master", 

"imageID": 
"docker://5630952871a38cddffda9ec611f5978ab0933628fcd54cd 
7d7677ce6b17de33f", 

"containerID": 
"docker://b0e2312643e9a4bb59cfiff5fb7a8468c5777180d5a 
8eabf2fOc9dfddcf3f4cd2" 


j 


接 下 来 实现 了 查看 Pod 的 log 日 志 功 能 ， 代 码 如 下 : 


privatevoid testLogPod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setSubPath("/1l0og"); 


params.setResourceType(ResourceType.PODS); 


_restfulClient.get(params); 


下 面 通过 API 访 问 Node 的 多 种 接口 ， 代 码 如 下 : 


privatevoid testPoxyNode() { 
Params params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("pods"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 


restfulClient.get(params); 


params - new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("stats"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 
_restfulClient.get(params); 
params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("spec"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 
_restfulClient.get(params); 
params = new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("run/ns-sample/pod/pod- 


sample-in-namespace"); 


params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES); 


 restfulClient.get(params); 


params - new Params(); 
params.setName("192.168.1.129"); 
params.setSubPath("metrics"); 
params.setVisitProxy(true); 
params.setResourceType(ResourceType.NODES) ; 


_restfulClient.get(params); 


了 最 后 ， 举 例 说 明 如 何 通过 API 删 除 资 源 对 象 pod， 代 码 如 下 : 


privatevoid testDetetePod() { 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setResourceType(ResourceType.PODS); 
LOG.info("Result:" 十 


_restfulClient.delete(params) ); 
} 


通过 API 接 口 除了 能 够 对 资源 对 象 实现 前 面 列 出 的 基本 操作 外 ， 
还 涉及 两 类 特殊 接口 ， 一 类 是 WATCH， 一 类 是 PROXY。 这 两 类 特殊 
接口 所 包含 的 接口 如 表 4.4 所 示 。 


AAA ”两 类 特殊 接口 所 包含 的 接口 


URL Path 


iA 


/api/vl/watch/nodes 


监听 所 有 节点 的 变化 


/api/v1/watch/nodes/ {name} 


监听 单个 节点 的 变化 


/api/v1/proxy/nodes/ {name}/{path:*} 


代理 DELETE 请 求 到 节点 的 某 个 子 
Hz 


/api/v1/proxy/nodes/ (name) / {path:*} 


代理 GET 请 求 到 节点 的 某 个 子 目录 


/api/v1/proxy/nodes/{name}/{path:*} 


代理 HEAD 请 求 到 节点 的 某 个 子 目 
录 


OPTIONS 


/api/v1/proxy/nodes/ {name} {path:*} 


代理 OPTIONS 请 求 到 节点 的 某 个 
fA 


/api/v1/proxy/nodes/ {name} /{path:*} 


代理 POST 请 求 到 节点 的 某 个 子 目 


/api/vl/proxy/nodes/ (name]/ [path:*] 


代理 PUT 请 求 到 节点 的 某 个 子 目录 


/api/v1/proxy/nodes/ {name} 


代理 DELETE 请 求 到 节点 


/api/v1/proxy/nodes/ {name} 


代理 GET 请 求 到 节点 


/api/vl/proxy/nodes/ {name} 


代理 HEAD 请 求 到 节点 


OPTIONS 


/api/v1/proxy/nodes/ {name} 


代理 OPTIONS 请 求 到 节点 


POST 


/api/v1/proxy/nodes/ {name} 


代理 POST 请 求 到 节点 


PUT 


/api/v1/proxy/nodes/ {name} 


代理 PUT 请 求 到 节点 


SERVICES 


/api/v1/watch/services 


监听 所 有 Service 的 变化 


/api/vl/watch/namespaces/ {namespace }/ 


services 


监听 某 个 Namespace 下 所 有 Service 


的 变化 


URL Path 说 


/api/vl/watch/namespaces/ (namespace] / 监听 某 个 Service 的 变化 
/api/vl/proxy/namezpaces/(namespace)/ | 代理 DELETE 请 求 到 Service 的 某 
services/{name}/{path:*} 个 子 目录 

japivliproxy/namespaces/{namespace}/ | 代理 GET 请 求 到 Service 的 某 个 子 
services/ {name}/{path:*} 目录 

e | /apu'v1 /proxy/namespaces/{namespace}/ | 代理 HEAD 请 求 到 Service 的 某 个 
services/ (name) / (path:*) FAR 

/api/vl/proxy/namespace:/ {namespace}! 代理 OPTIONS 请 求 到 Service 的 某 
services/{name}/{path:*} TF AR 
/api/vl/proxy/namespaces/(namespace)/ | 代理 POST 请 求 到 Service 的 某 个 子 
services/{name}/{path:*} 
/api/vl/proxy/namespaces/[namespace)/ | 代理 PUT 请 求 到 Service 的 某 个 子 
services/ (name] /(path:*] 
/api/vl/proxy/namespaces! [namespace] / , j 

PUT 代理 PUT 请 求 到 Service 
services/ {name} 
fs 


lapi vl^ s/ i Ws ur x n 9 
nd — itn 'watch/name:pacez/ {namespace} E : AX Namespace 下 所 有 RC 的 
ONTROLLER = TEE = 
/api'vl/watch/namespaces! {namespace}! » 
监听 某 个 RC 的 变化 


replicationcontrollers/ {name} 


ETET 
WATCH 


— /api/vl/watch/namespacez'(namespace]/ | 监听 某 个 Namespace 下 所 有 Pod 的 
pods 变化 


续 表 
| 资源 类 型 | 类 别 | 方 法 | —  (URPah | 


/api vl! ‘name: namespace} / 
pods/ {name} 


/api/vl/namespaces/(namespace]/pods/( | 代理 DELETE 请 求 到 Pod 的 某 个 子 
name}/proxy/ {path:*} 目录 


fapu'v lh / /pods/ 
apilvl/namespaces/{namespace}/pods/{ 代理 GET 请 求 到 Pod 的 某 个 子 目录 
name}/proxy/ {path:*} 


fapi/vl/namespaces/(namespace]/pods/( | 代理 HEAD WRP] Pod 的 某 个 子 目 
pes | 

name]/proxy/ {path:*} 子 目 录 

name}/proxy/ {path:*} 录 


l: 
api'v l/namespaces/ {namespace }/pods/{ 代理 PUT 请 求 到 Pod 的 某 个 子 目 录 
name)/proxy/ (path:*) 


Í; 1 
= /lapi/v 1 /mamespaces/ {namespace} /pods/( 代理 DELETE iff KR $j Pod 
name}/proxy 
/api/vl/ / : 
api/vl/namespaces/ {namespace }/pods/{ 代理 GET 请 求 到 Pod 
name}/proxy 


(apilvl/namespaces/{namespace}/pods/{ 代理 HEAD 请 求 到 Pod 
name}/proxy 


/apivli J h / 

aps Veamespaces/{namespoce}/Podsi{ | a OPTIONS il Pod 
name}/proxy 
上 lá J h 

osr | /aplvrlinamespaces/{fnamespacejipods/f 代理 POST 请 求 到 Pod 
name}/proxy 

lá 

mr | /api/vl/namespaces/ {namespace }/pods/{ 代理 PUT 请 求 到 Pod 

name}/proxy 


fapv'v1 /proxy/namespaces/{namespace}/ | 代理 DELETE 请 求 到 Pod 的 某 个 子 
pods/ (name] / {path:*} 目录 

/api/vl/proxy/namespaces/ {namespace}! 

pods/ {name} / (path:*] 

/api/vl/proxy/namespaces/(namespace]/ | 代理 HEAD 请 求 到 Pod 的 某 个 子 目 
Pods/{name}/{path:*} 


= : 
pods/{name}/ {path:*} FAR 
/api/vl/proxy/namespaces/(namespace)/ | 代理 POST 请 求 到 Pod HAFA 
pods/ (name) / (path:*] x 


代理 GET 请 求 到 Pod HRTF AR 


fh 3 大 lU h 5] f. i 

api'v1 /proxy/namespaces/ {namespace} 代理 GET 请 求 到 Pod 

pods/ {name} 

mo | ”| 代理 HEAD 请 求 到 Pod 
pods/ {name} 
/apivl/ oh = F / 

options | ^ proxy inamespaces (namespace)! | 代理 OPTIONS 请 求 到 Pod 

pods/ {name} 


lapi/vl4 rh / / 
POST éd as nowt eal fod 
pods! {name} 


续 表 
资源 类 型 | 类 别 | 方 法 | urpean | 说 用 | 
/api'vl/proxy/namespaces/ {namespace}/ 6 pares 
P 代理 PUT 请 求 到 Pod 
pods/ {name} 


| = 
监听 所 有 Endpoint 的 变化 


代理 PUT 请 求 到 Pod 的 某 个 子 目 录 
pods/ {name}/ {path:*} 
EN /api/vl/watch/namespaces/(namespace]/ | {i Wj X 4^ Namespace 下 所 有 
ENDPOINTS WATCH endpoints Endpoint 的 变化 
GET 


PUT 
GET 
UT 


/apivl/ f 5] / / 

omes api/vl/proxy/namespaces/ {namespace} 代理 DELETE WRA Pod 
pods! {name} 
/api/vl/watch/names, J / 
iac meque ome)! | 时 个 本 的 变化 
endpoints/ {name} 


监听 所 有 Service Account 的 变化 
SERVICRÁCCO cw /api/vl/watch/namespaces'[namespace)/ | {fi Wy M ^ Namespace 下 所 有 
WATCH ServiceAccount 的 变化 
/api/vl/watch/namespaces! {namespace} / 
GET wy spaces (namespace)! | HE ServiceAccount (Ett 
serviceaccounts/ {name} 
监听 所 有 Secret 的 变化 
/api/vl/watch/namespaces/[namespace]/ | 监听 某 个 Namespace 下 所 有 Secret 
SECRET WATCH secrets 的 变化 
/api/vl/watch/namespace:/ {namespace} / " 
GET 监听 某 个 Secret 的 变化 
secrets/ (name) 


监听 所 有 Event 的 变化 
EVENTS WATCH 


m /api/vl/watch/namespaces/[namespace]/ | 监听 某 个 Namespace 下 所 有 Event 
events 的 变化 


续 表 
| 资源 类 型 | 类 uja 法 | urean | m | 


| 监听 某 个 Event 的 变化 


psn 监听 所 有 Event 的 变化 
/api'vl/watch/namespaces/ {namespace} / KUA Namespace 下 所 有 Event 
LIMITRANGES | WATCH EE 的 变化 
/api/v1/watch/namespaces/ {namespace} / - 
s" i space | 监听 某 个 Event 的 变化 
limitranges/ {name} 


=<] Ifi RezourceQuota 的 变化 


/api/vl/watch/namespaces'(namespace]/ | {i "; XM. ^^ Namespace 下 所 有 
WATCH = ResourceQuota 的 变化 


'api/vl/watch/namespace:! {namespace} / 


RESOURCEQU 
OTAS 
监听 某 个 ResourceQuota 的 变化 


ee | eee {mame} 


= lapi'vl/watch/podtemplates 监听 所 有 PodTemplate 的 变化 


ge | ee {mamespace}/ | fi "5 X ^^ Namespace 下 所 有 
PODTEMPLATES | WATCH --Em PodTemplate 的 变化 


/api/vl/watch/namespaces/ {namespace} / 


监听 某 个 PodTemplate 的 变化 
"EL /(namej 


Fd — Ic | 'api/vl/watch/persistentvolumes ds Ur Bri PersistentVolume 的 变化 
Fd Ic | ‘apv'v1/watch/persistentvolumes/{name} | 监听 某 个 PersistentVolume 的 变化 


有 PersistentVolumeClaim 的 
/aplvl/watchperslstentvolumeclalms 


PERSISTENTV WATCH /api/vl/watch/namespaces/(namespace)/ | {i "T M ^ Namespace 下 所 有 
OLUMECLAIMS persistentvolumeclaims PersistentVolumeClaim 的 变化 
/api'v1/watch/namespaces/{mamespace}/ | 监听 某 个 PersistentVolumeClaim 的 


persistentvolumeclaims/ {name} 变化 


下 面 基于 Fabric8 实 现 对 资源 对 象 的 监听 (Watch) ， 代 码 如 下 : 


privatevoid testWatcher() { 
_kube.pods().watch(new 
io. fabric8.kubernetes.client.Watcher<Pod>() { 
QOverride 
publicvoid eventReceived(Action action, Pod pod) ( 
System.out.println(action + ": " + 


pod); 


@Override 
publicvoid onClose(KubernetesClientException e) { 


System.out.println("Closed: " + e); 


J): 


fee T KE T Jersey TEE Z8 SC EW iM wt Proxy 7; z& Jj lH] Pod ° H API 
Server 针 对 Pod 资 源 提 供 了 两 种 Proxy 访 问 接口 ， 所 以 下 面 分 别 用 两 段 
代码 进行 示例 说 明 。 代 码 如 下 : 


privatevoid testPoxyPod() { 


// 访 问 第 1 种 proxy 接 口 
Params params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 
params.setSubPath("/proxy"); 


params.setResourceType(ResourceType.PODS); 


_restfulClient.get(params); 


// 访 问 第 2 种 proxy 接 口 
params = new Params(); 
params.setNamespace("ns-sample"); 
params.setName("pod-sample-in-namespace"); 


params.setVisitProxy(true); 


params.setResourceType(ResourceType.PODS); 


 restfulClient.get(params); 
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Kubernetes 集 群 本 身 也 需要 进行 相应 的 配置 和 管理 。 本 章 将 从 
Kubernetes 集 群 管理 、 高 级 案例 及 Trouble Shooting 等 方面 对 Kubernetes 
集群 的 运 维和 查 错 进行 详细 说 明 ， 最 后 对 Kubernetes1.3 版 本 开发 中 的 
新 功能 进行 介绍 


5.1 Kubernetes 集 群 管理 指责 


本 下 将 从 Node 的 管理 、Label 的 管理 、Namespace 资 源 共 享 、 资 源 
配额 管理 、 集 群 Master 高 可 用 及 集群 监控 等 方面 ， 对 Kubernetes 集 群 本 
身 的 运 维 管理 进行 详细 说 明 。 


5.1.1 Node 的 管理 


1.Node 的 隅 离 与 恢复 


在 硬件 升级 、 和 硬件 维护 等 情况 下 ， 我 们 需要 将 某 些 Node 进 行 隔 
离 ， 脱 离 Kubernetes 集 群 的 调度 范围 。Kubernetes 提 供 了 一 种 机 制 ， 既 
可 以 将 Node 纳 入 调度 范围 ， 也 可 以 将 Node 脱 离 调 度 范 围 。 


创建 配置 文件 unschedule node.yaml ， 在 spec 部 分 指定 


unschedulable 为 true: 


apiVersion: vi 
kind: Node 
metadata: 
name: k8s-node-1 
labels: 
kubernetes.io/hostname: k8s-node-1 
spec: 


unschedulable: true 
然后 ， 通 过 kubectl replace tit S 55 X] Node TA 4845 EX : 


$ kubectl replace -f unschedule node.yaml 


node "k8s-node-1" replaced 


查看 Node 的 状态 ， 可 以 观察 到 在 Node 的 状态 中 增加 了 一 项 
SchedulingDisabled: 


# kubectl get nodes 
NAME STATUS AGE 
k8s-node-1 Ready, SchedulingDisabled 1h 


对 于 后 续 创 建 的 Pod， 系 统 将 不 会 再 向 该 Node 进 行 调度 。 
也 可 以 不 使 用 配置 文件 ， 直 接 使 用 kubectl patch 命 令 完 成 : 


$ kubectl patch node k8s-node-1 -p '{"spec": 


{"unschedulable":true}}' 


需要 注意 的 是 ， 将 某 个 Node 脱 离 调度 范围 时 ， 在 其 上 运行 的 Pod 
并 不 会 目 动 俘 止 ， 管 理 员 需要 手动 停止 在 该 Node 上 运行 的 Pod。 


同样 ， 如 果 需 要 将 某 个 Node 重 新 纳入 集群 调度 范围 ， 则 将 
unschedulable 设 置 为 false， 再 次 执行 kubectl replace 或 kubectl patch 命 令 
束 能 恢复 系统 对 该 Node 的 调度 。 


在 Kubernetes 当 前 的 版 本 中 ，kubectl 的 子 命令 cordon 和 uncordon 也 
用 于 实现 将 Node 进 行 隔离 和 恢复 调度 的 操作 。 

例如 ， 使 用 kubectl cordon<node_name> 对 某 个 Node 进 行 隔离 调度 
操作 : 


# kubectl cordon k8s-node-1 


node "k8s-node-1" cordoned 


# kubectl get nodes 
NAME STATUS AGE 
k8s-node-1 Ready, SchedulingDisabled 1h 

使 用 kubectl uncordon 


4 FH kubectl uncordon«node name» 3 ^ Node 3# 17 PX d ys] RE PR 
TE: 


# kubectl uncordon k8s-node-1 


node "k8s-node-1" uncordoned 
# kubectl get nodes 


NAME STATUS AGE 
k8s-node-1 Ready 1h 


2.Node 的 扩容 


EXE ARP SA Bias MMB BAST AEHJIBOU, XP UNS 
要 购买 新 的 服务 器 ， 然 后 将 应 用 系统 进行 水 平 扩展 来 完成 对 系统 的 扩 


pil 中 ， 一 个 新 Node 的 加 入 是 非常 简单 的 。 在 新 的 
Node 万 点 上 安装 Docker、kubelet 和 kube-proxy 服 务 ， 然 后 配置 kubelet 
和 kube-proxy 的 局 动 参数 ， 将 Master URD 定 为 当前 Kubernetes 集 群 
Master 的 地 址 ， 最 后 启动 这 些 服务 。 通 过 kubelet 默 认 的 上 自动 注册 机 
制 ， 新 的 Node 将 会 目 动 加 入 现 有 的 Kubernetes 集 群 中 ， 如 图 5.1 所 示 。 


Kubernetes | 
Master 


HOME Pee 
- ENG 
S 
N 
XX 


oe a » 
- 
-i ~ 
L 
/ . Kubelet | 
/ we 
; 
—api servers-http:// 
á Node kubemaster:8080 
I 
| 


Node 


Kubernetes £t ilt 


图 5.1 新 节点 自动 注册 完成 扩容 


Kubernetes Master 在 接受 了 新 Node 的 注册 之 后 ， 会 自动 将 其 纳入 
当前 集群 的 调度 范围 内 ， 在 之 后 创建 容器 时 ， 就 可 以 癌 新 的 Node 进 行 
调度 了 。 


通过 这 种 机 制 ，Kubernetes 实 现 了 集群 中 Node 的 扩容 。 


5.1.2 ”更 新 资源 对 象 的 Label 


Label (标签 ;作为 用 户 可 灵活 定义 的 对 象 属性 ， 在 正在 运行 的 资 
源 对 象 上 ， 人 仍然 可 以 随时 通过 kubectl label 命 令 对 其 进行 增加 、 修 改 、 


删除 等 操作 。 
例如 ， 我 们 要 给 已 创建 的 Pod“redis-master-bobr0” 添 加 一 个 标签 


role=backend: 


$ kubectl label pod redis-master-bobrO role=backend 


pod "redis-master-bobrO" labeled 


查看 该 Pod 的 Label: 


$ kubectl get pods -Lrole 


NAME READY STATUS RESTARTS 
AGE ROLE 
redis-master-bobrO 1/1 Running 0 3m 
backend 
删除 一 个 Label 时 ， 只 需 在 命令 行 最 后 指定 Label 的 key 名 并 与 一 个 
减 号 相连 即 可 : 


$ kubectl label pod redis-master-bobrO role- 


pod "redis-master-bobr0" labeled 


修改 一 个 Label 的 值 时 ， 需 要 加 上 --overwrite 参 数 : 


$ kubectl label pod redis-master-bobrO role=master -- 
overwrite 


pod "redis-master-bobrO" labeled 


5.1.3 Namespace: 集群 环境 共享 与 隅 离 


在 一 个 组 织 内 部 ， 不 同 的 工作 组 可 以 在 同一 个 Kubernetes 集 群 中 
工作 ，Kubernetes 通 过 命名 空间 和 Context 的 设置 来 对 不 同 的 工作 组 进 
行 区 分 ， 使 得 它们 既 可 以 共享 同一 个 Kubernetes 集 群 的 服务 ， 也 能 够 
互 不 干扰 ， 如 图 5.2 所 示 。 


Namespace: Dev Namespace: Prod 


5.2 ”集群 环境 共 至 和 隔离 


假设 在 我 们 的 组 织 中 有 两 个 工作 组 :开发 组 和 生产 运 维 组 。 开 发 
组 在 Kubernetes 集 群 中 需要 不 断 创 建 、 修 改 、 删 除 各 种 Pod、RC、 
Service 等 资源 对 象 ， 以 便 实现 敏捷 开发 的 过 程 。 而 生产 运 维 组 则 需要 
使 用 严格 的 权限 设置 来 确保 生产 系统 中 的 Pod、RC、Service 处 于 正常 
运行 状态 且 不 会 被 误 操 作 。 


1. 创 建 namespace 


为 了 在 Kubernetes 集 群 中 实现 这 两 个 分 组 ， 首 先 需 要 创建 两 个 命 
名 空间 。 


namespace-development.yaml: 


apiVersion: v1 
kind: Namespace 
metadata: 


name: development 


namespace-production.yaml: 


apiVersion: v1 
kind: Namespace 
metadata: 


name: production 


使 用 kubectl create 命 令 完 成 命名 空间 的 创建 : 


$ kubectl create -f namespace-development.yaml 


namespaces/development 


$ kubectl create -f namespace-production.yaml 


namespaces/production 


查看 系统 中 的 命名 空间 : 


$ kubectl get namespaces 

NAME LABELS STATUS 
default <none> Active 
development name=development Active 


production name=production Active 


2.6 “Context (运行 环境 ) 


M 需要 为 这 两 个 工作 组 分 别 定 义 一 个 Context， 即 运行 环 
境 。 这 个 运行 环境 将 属于 某 个 特定 的 命名 空间 。 


通过 kubectl config set-context 命 令 定义 Context， 并 将 Context 置 于 


之 前 创建 的 命名 空间 中 : 


$ kubectl config set-cluster kubernetes-cluster -- 
server=https://192.168.1.128:8080 
$ kubectl config  set-context  ctx-dev  -- 
namespace-development --cluster=kubernetes-cluster -- 
user-dev 
$ kubectl config  set-context  ctx-prod  -- 
namespace-production --cluster=kubernetes-cluster -- 


user=prod 


使 用 kubectl config view 命 令 查看 已 定义 的 Context: 


$ kubectl config view 


apiVersion: vi 


clusters: 
- cluster: 
server: http://192.168.1.128:8080 
name: kubernetes-cluster 
contexts: 
- context: 
cluster: kubernetes-cluster 
namespace: development 
name: ctx-dev 
- context: 
cluster: kubernetes-cluster 
namespace: production 
name: ctx-prod 
current-context: ctx-dev 
kind: Config 
preferences: {} 


users: [] 


注意 ， 通 过 kubect config ti + ${HOME}/.kube H 5€ P AE B, f — 
个 名 为 config 的 文件 ， 文 件 内 容 即 以 kubectl config view 命 令 查看 到 的 内 
容 。 所 以 ， 也 可 以 通过 手工 编辑 该 文件 的 方式 来 设置 Context ° 


3. 设 置 工作 组 在 特定 Context 环 境 中 工作 


使 用 kubectl config use-context<context_name> 命 令 来 设置 当前 的 运 
行 环境 。 


下 面 的 命令 将 把 当前 运行 环境 设置 为 “ctx-dev”: 


$ kubectl config use-context ctx-dev 


通过 这 个 命令 ， 当 前 的 运行 环境 即 被 设置 为 开发 组 所 需 的 环境 。 
之 后 的 所 有 操作 都 将 在 名 为 “development” 的 命名 空间 中 完成 。 


现在 ， 以 redis-slave RC 为 例 创 建 两 个 Pod: 
redis-slave-controller.yaml 


apiVersion: v1 
kind: ReplicationController 
metadata: 
name: redis-slave 
labels: 
name: redis-slave 
spec: 
replicas: 2 
selector: 
name: redis-slave 
template: 
metadata: 
labels: 
name: redis-slave 
spec: 
containers: 


- name: slave 


image: kubeguide/guestbook-redis-slave 
ports: 


- containerPort: 6379 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontrollers/redis-slave 


查看 创建 好 的 Pod: 


$ kubectl get pods 
NAME READY STATUS 
RESTARTS AGE 
redis-slave-Ofeq9 1/1 Running 0 
6m 
redis-slave-6i0g4 1/1 Running 0 
6m 
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环境 是 ctx-dev， 所 以 不 会 影响 到 生产 运 维 组 的 工作 。 


让 我 们 切换 到 生产 运 维 组 的 运行 环境 : 
$ kubectl config use-context ctx-prod 
查看 RC 和 Pod: 


$ kubectl get rc 


CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR 


REPLICAS 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
结果 为 室 ， 说 明 看 不 到 开发 组 创建 的 RC 和 Pod。 
现在 我 们 为 生产 运 维 组 也 创建 两 个 redis-slave 的 Pod: 


$ kubectl create -f redis-slave-controller.yaml 


replicationcontrollers/redis-slave 
查看 创建 好 的 Pod: 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
redis-slave-a4m7s 1/1 Running 0 12s 
redis-slave-xyrkk 1/1 Running 0 12s 


可 以 看 到 容器 被 正确 创建 并 运行 起 来 了 ， 并 且 当 前 的 运行 环境 是 
ctx-prod， 也 不 会 影响 开发 组 的 工作 。 


至 此 ， 我 们 为 两 个 工作 组 分 别 设 置 了 两 个 运行 环境 ， 在 设置 好 当 
前 的 运行 环境 时 ， 各 工作 组 之 间 的 工作 将 不 会 相互 和 干扰， 并且 它 们 都 
能 够 在 同一 个 Kubemetes 集 群 中 同时 工作 9 


5.1.4 Kubernetes 资 源 管 理 


本 章 从 计算 资源 管理 (Compute Resources) 、 资 源 配置 范围 管理 
(LimitRange ) 、 服 务 质 量 管 理 ( QoS) 资源 配额 管理 
(ResourceQuota) 等 方面 ， 对 Kubernetes 集 群 内 的 资源 管理 进行 详细 

说 明 ， 结 合 实践 操作 、 常 见 问 题 分 析 和 一 个 完整 的 示例 ， 对 
Kubernetes 集 群 资源 管理 相关 的 运 维 工作 提供 指导 。 


1. 计 算 资 源 管理 (Compute Resources) 


在 配置 Pod 的 时 候 ， 我 们 可 以 为 其 中 的 每 个 容器 指定 需要 使 用 的 
计算 资源 (CPU 和 内 存 ) 。 


计算 资源 的 配置 项 分 为 两 种 : 一 种 是 资源 请 求 (Resource 
Requests， 人 简称 Requests) ， 表 示 容 器 希望 被 分 配 到 的 、 可 完全 保证 的 
资源 量 ，Requests 的 值 会 提供 给 Kubernetes 调度 器 (Kubernetes 
Scheduler) 以 便于 优化 基于 资源 请 求 的 容器 调度 ;另外 一 种 是 资源 限 
制 (Resource Limits， 人 简称 Limits) ，Limits 是 容器 最 多 能 使 用 到 的 资 
产量 的 上 限 ， 这 个 上 限 值 会 影响 节点 上 发 生 资 源 苋 搜 时 的 解决 策略 。 


当前 版 本 的 Kubernetes 中 ， 计 算 资 源 的 资源 类 型 分 为 两 种 : CPU 和 
AF (Memory) 。 这 两 种 资源 类 型 都 有 一 个 基本 单位 : 对 于 CPU 而 
言 ， 基 本 单位 是 核心 数 (Cores) ; 而 内 存 的 基本 单位 是 字 节 数 
(Bytes) 。CPU 和 内 存 一 起 构成 了 目前 Kubernetes 中 的 计算 资源 (也 
可 简称 为 资源 ) 。 


计算 资源 是 可 计量 的 ， 能 被 申请 、 分 配 和 使 用 的 基础 资源 ， 这 使 
之 区 别 于 API 资 源 (API Resources， 例 如 Pod 和 services 等 ) 。 


1) Pod#l 44s HJRequests# Limits 


Pod P B BT sis eb n] LAB EL RAS BRK o 


spec.container[].resources.requests.cpu ° 


spec.container[].resources.limits.cpu ° 


spec.container| |.resources.requests.memory ° 


spec.container| |.resources.limits.memory ° 


这 四 个 参数 分 别 对 应 容器 的 CPU 和 内 存 的 Redquests 和 Limits， 它 们 
具有 以 下 特点 。 


e Requests 和 Limits 都 是 可 选 的 。 在 某 些 集群 中 如 果 在 Pod 创 建 或 者 
更 新 的 时 候 ， 没 设置 资源 限制 或 者 资源 请 求 值 ， 那 么 可 能 会 使 用 
系统 提供 一 个 默认 值 ， 这 个 默认 值 取决 于 集群 的 配置 。 

。 如 末 Request 没 有 配置 ， 那 么 默认 会 被 设置 为 等 于 Limits ° 

。 而 任何 情况 下 Limits 都 应 该 设置 为 大 于 或 者 等 于 Requests。 


以 CPU 为 例 ， 图 5.3 显 示 了 未 设置 CPU Limits 和 设置 CPU Limits 的 
CPU 使 用 率 的 区 别 。 


未 设置 CPU Limits 的 CPU 使 用 率 设置 了 CPU Requests 和 CPU Limits 
的 CPU 使 用 


CPU Limits: 0.8 C 


图 5.3 ”未 设置 和 设置 了 CPU Limits 的 CPU 使 用 率 样 例 


尽管 Requests 和 Limits 只 能 设置 到 容器 上 ， 但 是 设置 Pod 级 别 的 
Requests 和 Limits 能 极 大 程度 上 提高 我 们 对 Pod 管 理 的 便利 性 和 有 灵活 
性 ， 因 此 Kubemetes 中 提供 对 Pod 级 别 的 Requests 和 Limits 配 置 。 对 于 
CPU 和 内 存 而 言 ，Pod 的 Requests 或 Limits 是 指 该 Pod 中 所 有 容器 的 
Requests 或 Limits 的 总 和 (Pod 中 没 设置 Request 或 Limits 的 容器 ， 该 项 
的 值 被 当 作 0 或 者 按照 集群 配置 的 默认 值 来 计算 ) 。 下 面 对 CPU 和 内 存 
这 两 种 计算 资源 各 目的 特点 进行 说 明 。 


(1) CPU 


CPU 的 Requests 和 Limits 是 通过 CPU 数 (cpus) 来 度量 的 。CPU 资 
源 值 文 持 最 多 三 位 小 数 : 如 有 果 一 个 容器 的 
spec.container[].resources.requests.cpu 设 置 为 0.5， 那 么 它 会 获得 半 个 
CPU; 同 理 如 采 设 置 为 1， 就 会 获得 1 个 CPU。0.1CPU 等 价 于 100m 
CPU (100millicpu) ， 而 在 Kubernetes API 中 自动 将 这 种 小 数 0.1 转 化 为 
100m， 因 此 CPU 的 小 数 最 多 支持 三 位 数字 ， 而 Kubernetes 官 方 也 更 推 
荐 直接 使 用 形 如 100m 的 millicpu 作 为 计量 单位 。 


CPU 资源 值 是 绝对 值 ， 而 不 是 相对 值 : 比如 0.1CPU 不 管 是 在 单 核 
或 者 多 核 机 器 上 都 是 一 样 的 ， 都 严格 等 于 0.1CPU core 。 


(2) 内 存 (Memory) 


内 存 的 Requests 和 Limits 计 量 单位 是 字 节 数 (Bytes) 。 内 存 值 用 使 
用 整数 或 者 定点 整数 加 上 国际 单位 制 (International System of Units) 
来 表示 。 国 际 单位 制 包括 十 进 制 的 E、P、T、G、M、K、m, 或 二 进 
制 的 Ei、Pi、Ti、Gi、Mi、Ki。 比 如 : KiB 与 MiB 是 二 进 制 表 示 的 字 市 


单位 ， 而 常见 的 KB 与 MB 则 是 十 进 制 表 示 的 字 节 单位 。 两 种 方式 的 区 
别 举例 说 明 如 下 : 


1KB (kilobyte) =1000bytes=8000bits 


1KiB (kibibyte) =2^10bytes=1024bytes=8192bits 


因此 ， 下 面 几 种 内 存 配 置 的 意思 是 一 样 的 : 128974848、129e6、 
129M ^ 123Mi 


Kubemetes 的 计算 资源 单位 是 大 小 写 敏感 的 ， 因 为 m 可 以 表示 干 分 
之 一 单位 (milliuni) ， 而 M 可 以 表示 十 进 制 的 1000， 两 者 的 含义 不 
同 ， 同 理 可 知 ， 小 写 的 k 不 是 一 个 合法 的 资源 单位 。 


以 一 个 Pod 中 的 资源 配置 为 例 : 


apiVersion: vi 
kind: Pod 
metadata: 
name: frontend 
spec: 
containers: 
- name: db 
image: mysql 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 


limits: 


memory: "128Mi" 
cpu: "500m" 
- name: wp 
image: wordpress 
resources: 
requests: 
memory: "64Mi" 
cpu: "250m" 
limits: 
memory: "128Mi" 


cpu: "500m" 
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64MiB (27%bytes) 内 存 ， 而 配置 的 Limits 都 是 0.5CPU fill 128MiB 
(227bytes) 内 存 。 


这 个 Pod 的 Requests 和 Limits 等 于 Pod 中 所 有 容器 对 应 配置 的 总 和 ， 
所 以 Pod 的 Requests 是 0.5CPU 和 128MiB (22/bytes) 内 存 ，Limits 是 
1CPU 和 256MiB (228bytes) 内 存 。 


2) 基于 Requests 和 Limits 的 Pod 调 度 机 制 


当 一 个 Pod 创 建成 功 时 ，Kubernetes 调 度 器 (Scheduler) 为 该 Pod 
选择 一 个 节点 (Node) 来 执行 。 对 于 每 种 计算 资源 (CPU 和 内 存 ) 而 
言 ， 每 个 慷 点 都 有 一 个 能 用 于 运行 Pod 的 最 大 容量 值 。 调 度 絮 在 调度 
时 ， 首 先 要 确保 调度 后 该 节点 上 所 有 Pod 的 CPU 和 内 存 的 Requests 总 和 
不 能 超过 该 节点 能 提供 给 Pod 使 用 的 CPU 和 内 存 的 最 大 容量 值 。 


例如 某 个 节点 上 CPU 资源 充足 ， 而 内 存 为 4GB， 其 中 3GB 可 以 运 
行 Pod， 某 Pod 的 内 存 Requests 为 1GB、Limits 为 2GB， 那 么 这 个 节点 上 
最 多 可 运行 3 个 这 种 Pod 。 


这 里 需要 注意 的 是 : 可 能 某 些 和 点 上 的 实际 资源 使 用 量 非 常 低 ， 
但 是 如 果 该 节点 上 已 运行 Pod 配 置 的 Requests 值 的 总 和 已 经 非常 高 ， 
加 上 需要 调度 的 Pod 的 Requests 值 会 直接 超过 该 和 点 提供 给 Pod 的 资源 
容量 上 限 ，Kubernetes 仍 然 不 会 将 Pod 调 上 度 到 这 个 节点 上 。 这 是 因为 如 
果 Kubernetes 将 Pod 调 度 到 该 节点 上 ， 那 么 如 果 后 面 该 节点 上 运行 的 
Pod 面 临 服务 峰值 等 情况 ， 可 能 会 导致 Pod 资 源 短 缺 的 情况 发 生 。 


接着 上 面 的 例子 ， 假 设 该 玉 点 已 经 启动 3 个 Pod 实 例 ， 而 这 3 个 Pod 
的 实际 内 存 使 用 都 不 足 500MB ， 那 么 理论 上 该 节点 的 可 用 内 存 应 该 大 
于 1.5GB， 但 是 由 于 该 节点 的 Pod Requests 总 和 已 经 等 于 节点 的 可 用 内 
存 上 限 ， 因 此 Kubernetes 不 会 再 将 任何 Pod 实 例 调度 到 该 节点 上 执行 。 


3) Requests 和 Limits 资 源 配置 机 制 


当 kubelet 局 动 Pod 的 一 个 容器 时 ， 它 会 将 容器 的 Redquests 和 Limits 
值 转化 为 相应 的 容器 启动 参数 传递 给 容器 执行 器 (Docker 或 者 是 
rkt) 。 


如 果 容 器 的 执行 环境 是 Docker， 那 么 容器 的 4 个 参数 是 这 样 传递 给 
Docker 的 。 


(1) spec.container[].resources.requests.cpu 


这 个 参数 会 转化 为 core 数 〈 比 如 配置 的 100m 会 转化 为 0.1) ， 然 后 
乘 以 1024， 再 将 这 个 结果 作为 --<cpu-shares 参 数 的 值 传递 给 docker run 命 


& o docker run 命 令 中 ，--cpu-share 人 参数 是 一 个 相对 权重 值 (Relative 
Weight) ， 这 个 相对 权重 值 会 决定 Docker 在 资源 竞争 时 分 配给 容器 的 
资源 比例 。 举 例 说 明 --cpu-shares 参 数 在 Docker 中 的 含义 : 比如 两 个 容 
88 HJCPU Requests 分 别 设置 为 1 和 和 2， 那么 容器 在 docker run 启 动 时 对 应 
的 --cpu-shares 参 数值 分 别 为 1024 和 2048， 在 主机 CPU 资源 产生 竞争 
时 ，Docker 会 尝试 按照 1:2 的 配 比 将 CPU 资源 分 配给 这 两 个 容 需 使 用 。 


这 里 需要 区 分 清楚 的 是 : 这 个 参数 对 于 Kubernetes 而 言 是 绝对 
值 ， 主 要 用 于 Kubernetes 调 度 和 管理 的 依据 〈 参 见 下 文 QoS 章 和 ) ; 同 
时 这 个 参数 值 会 设置 为 --cpu-shares 参 数 传递 给 Docker，--cpu-shares 参 
数 对 于 Docker 而 言 又 是 相对 值 ， 主 要 用 于 资源 分 配 比例 。 这 两 种 用 途 
的 作用 范围 不 同 ， 所 以 并 不 会 发 生 神 突 。 


(2) spec.container[].resources.limits.cpu 


这 个 参数 会 转化 为 millicore 数 (比如 配置 的 1 会 转化 为 1000， 而 配 
置 的 100m 转 化 为 100) ， 将 此 值 乘 以 100000， 再 除 以 1000， 然 后 将 结 
果 值 作为 --cpu-quota 参 数 的 值 传递 给 docker run 命 令 。docker run 命 令 中 
男 外 一 个 参数 --cpu-period 默 认 设 置 为 100000， 表 示 Docker 重 新 计量 和 
分 配 CPU 的 使 用 时 间 间 隔 为 100000 微 秒 (1002& P) 。 


Docker f‘)--cpu-quota 2 Fil --cpu-period Z: Zt — x& Ad & 5e BMT A at 
CPU 的 使 用 限制 : 比如 Kubernetes 中 配置 容器 的 CPU Limits7j0.1, JB 
么 计算 后 --cpu-quota 为 10000 ， 而 --cpu-period 为 100000， 这 意味 着 
Docker Æ 1002€ f [A] gt e 25 KA 88 2) BC 10 2& * core YT 53-51 JH E , 
10/100=0.1core 的 结果 与 Kubernetes 配 置 的 意义 是 一 致 的 。 


注意 : WR kubelet A 2/] & 23 --cpu-cfs-quota i: & A true, Hh A 
kubelet 会 强制 要 求 所 有 Pod 都 必须 配置 CPU Limits (如 有 果 Pod 没 配置 ， 
而 集群 提供 了 默认 配置 也 可 以 ) 。 而 从 Kubernetes 1.2 版 本 开始 ， 这 个 - 
-cpu-cfs-quota 启 动 参数 的 默认 值 束 是 true。 


(3) spec.container[].resources.requests. memory 


这 个 参数 值 只 提供 给 Kubernetes 调 度 器 (Kubernetes Scheduler) 作 
为 调度 和 管理 的 依据 ， 不 会 作为 任何 参数 传递 给 Docker 。 


(4) spec.container[].resources.limits.memory 


这 个 参数 值 会 转化 为 单位 为 bytes 的 整数 ， 数 值 会 作为 -memory 参 


RUE EA docker run 命 令 。 


如 果 一 个 容器 在 运行 过 程 中 使 用 了 超出 了 其 内 存 Limits 配 置 的 内 
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器 ， 那 么 之 后 它 会 被 kubelet 重 新 局 动 起 来 。 因 此 容 髓 的 Limits 配 置 需 
要 进行 准确 的 测试 和 评估 o 


与 内 存 Limits 不 同 的 是 CPU 在 容 右 技术 中 属于 可 压缩 资源 ， 因 此 
对 于 CPU 的 Limits 配 置 一 般 不 会 引发 因 侦 然 超标 使 用 而 导致 容器 被 系 
统 “ 杀 挥 ” 的 情况 。 


4) 计算 资源 使 用 情况 监控 


Pod 的 资源 用 量 会 作为 Pod 的 状态 信息 一 同上 报 给 Master。 如果 集 
群 中 配置 了 Heapster 来 监控 集群 的 性 能 数据 ， 那 么 还 可 以 从 Heapster 中 
查看 Pod 的 资源 用 量 信息 。 


5) 计算 资源 相关 常见 问题 分 析 
(1) Pod 状 态 为 pending， 错 误 信 息 为 FailedScheduling ° 


如 果 Kubernetes 调 度 器 (Kubernetes Scheduler) 在 集群 中 找 不 到 合 
适 的 节点 来 运行 pod， 那 么 这 个 Pod 会 一 直 处 于 未 调度 状态 ， 直 到 调度 
名 找 到 合适 的 广 点 为 止 。 每 次 调度 絮 尝 试 调度 失败 ，Kubernetes 都 会 
产生 一 个 事件 (event) ， 我 们 可 以 通过 下 面 这 种 方式 来 查看 事件 的 信 
E. 


JON 。 


$ kubectl describe pod frontend | grep -A 3 Events 


Events: 
FirstSeen LastSeen Count From 
Subobject PathReason Message 
36s 5S 6 
{scheduler } FailedScheduling Failed for reason 


PodExceedsFreeCPU and possibly others 


在 上 面 这 个 例子 中 ， 和 名 为 frontend 的 Pod 由 于 节点 的 CPU 资源 不 足 
而 调度 失败 (PodExceedsFreeCPU) ， 同 样 ， 如 果 内 存 不 足 也 可 能 导 
致 调度 失败 (PodExceedsFreeMemory) ° 


如 有 宁 一 个 或 者 多 个 Pod 调 度 失败 且 有 这 类 错误 ， 那 么 我 们 可 以 稳 
试 以 下 儿 种 解决 方法 。 


。 添加 更 多 的 节点 到 集群 中 。 
。 停止 一 些 不 必要 的 运行 中 的 Pod， 释 放 资 源 。 


。 检查 Pod 的 配置 ， 错 误 的 配置 可 能 导致 该 Pod 永 远 都 无 法 被 调度 执 
行 。 比 如 如 果 整 个 集群 中 所 有 市 点 都 只 有 1CPU， 而 Pod 配 置 的 
CPU Requests 为 2， 那 么 该 Pod 就 不 会 被 调度 执行 。 


我 们 可 以 使 用 kubectl describe nodes 命 令 来 查看 集群 中 和 点 的 计算 
资源 容量 和 已 使 用 量 : 


$ kubectl describe nodes k8s-node-1 


Name : k8s-node-1 


Capacity: 
cpu: 1 
memory: 464Mi 
pods: 40 
Allocated resources (total requests): 
cpu: 910m 


memory: 2370Mi 


pods: 4 
Pods: (4 in total) 
Namespace Name 
CPU(milliCPU) Memory(bytes) 
frontend webserver -ffj8j 
500 (50% of total) 2097152000 (50% of total) 
kube-system fluentd-cloud- 
logging-k8s-node-1 100 (10% of total) 


209715200 (5% of total) 


kube-system kube-dns-v8-qopgw 


310 (31% of total) 178257920 (4% of total) 
TotalResourceLimits: 
CPU(milliCPU): 910 (91% of total) 
Memory(bytes): 2485125120 (59% of total) 


超过 可 用 资源 容量 上 限 (Capacity) 和 Vi (Allocated 
resources) 差额 的 Pod 无 法 运行 在 该 Node 上 。 这 个 例子 中 ， 如 果 一 个 
Pod 的 Requests 超 过 90millicpus 或 者 超过 1341MiB 存 ， 那 么 就 无 法 运 
行 在 这 个 和 点 上 。 


在 后 面 的 资源 配额 (Resource Quota) 章节 中 ， 我 们 还 可 以 配置 针 
对 一 组 Pod 的 Requests 和 Limits 总 量 的 限制 ， 这 种 限制 可 以 作用 于 命名 
空间 ， 通 过 这 种 方式 我 们 可 以 防止 一 个 命名 空间 下 的 用 户 将 所 有 资源 
全 部 据 为 已 有 。 


(2) 容器 被 强行 终止 (Terminated) 
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被 强制 终止 。 我 们 可 以 通过 kubectl describe pod 命 令 来 确认 容器 是 否 是 
因为 这 个 原因 被 终止 的 : 


$ kubectl describe pod simmemleak-hra99 


Name: simmemleak-hra99 
Namespace: default 
Image(s): saadali/simmemleak 


Node: 192.168.18.3 


Labels: 
Status: 
Reason: 
Message: 
IP: 
Replication Controllers: 
replicas created) 
Containers: 
simmemleak: 
Image:  saadali/simmemleak 
Limits: 
cpu: 
memory : 
State: 
Started: 
12:54:41 -0700 
Last Termination State: 
Exit Code: 
Started: 
12:54:30 -0700 
Finished: 
12:54:33 -0700 
Ready: 
Restart Count: 
Conditions: 
Type Status 


Ready False 


name-simmemleak 


Running 


112.175.1.3 


simmemleak (1/1 


100m 
50Mi 
Running 


Tue, 07 Jul 2015 


Terminated 


1 


Fri, 07 Jul 2015 


Fri, 07 Jul 2015 


False 


Events: 
FirstSeen LastSeen 
Count From SubobjectPath 
Reason Message 
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 
12:53:51 -0700 1 (scheduler } 
scheduled Successfully assigned simmemleak-hra99 to 
kubernetes-node-tfOf 


Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 


12:53:51 -0700 1 (kubelet kubernetes-node-tfOf) 
implicitly required container POD pulled Pod 
container image "gcr.io/google containers/pause:0.8.0" 


already present on machine 

Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 
12:53:51 -0700 1 (kubelet kubernetes-node-tfOf) 
implicitly required container POD created Created 
with docker id 6a41280f516d 

Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 
12:53:51 -0700 1 (kubelet kubernetes-node-tfOf) 
implicitly required container POD started Started 
with docker id 6a41280f516d 

Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 
12:53:51 -0700 1 (kubelet kubernetes-node-tfOf) 
spec.containers{simmemleak} created Created 


with docker id 87348f12526a 


Restart Count: 5 说 明 这 个 名 为 simmemleak 的 容器 被 强制 终止 并 重 


启 了 5 次 。 


我 们 可 以 在 使 用 kubectl get pod 命 令 时 添加 -o go-template=... 格 式 参 


数 来 读 取 已 终止 容器 之 前 的 状态 信息 : 


F 


的 ， 


$ kubectl get pod -0 go- 
template='{{range.status.containerStatuses}}{{"Container 
Name: "bi {{.name}}{{"\r\nLastState: "}}{{.lastState}} 
{{end}}' simmemleak-60xbc 
Container Name: simmemleak 

LastState: map[terminated:map[exitCode:137 reason :00M 
Killed startedAt:2015-07-07T20:58:43Z  finishedAt:2015-07- 
07T20:58:43Z 
containerID:docker://0e4095bbadfeccdfe7ef9fb6ebffe972b4b142 
85d5acdecef0d3ae8a22fad8b2]] 


这 里 我 们 可 以 看 到 这 个 容器 因为 reason: OOM Killed 而 被 强制 终 
说 明 这 个 容器 的 内 存 超过 了 限制 (Out of Memory) ° 


6) 计算 资源 管理 的 演进 


当前 版 本 的 Kubemetes 中 的 Requests 和 Limits 都 是 作用 于 容器 级 别 
未 来 Kubernetes 计 划 增 加 对 直接 作用 于 Pod 级 别 的 资源 配置 的 支 
这 种 资源 配置 是 能 被 Pod 内 的 所 有 窑 絮 共享 的 ， 包 括 emptyDir 这 种 


Pod 级 别 的 Volume ° 


从 资源 的 种 类 来 看 ， 目 前 Kubernetes 只 能 文 持 CPU 和 内 存 两 种 计算 


资源 类 型 ， 在 后 续 的 版 本 中 ，Kubernetes 计 划 支 持 更 多 的 资源 类 型 ， 
包括 市 点 伺 盘 空间 资源 ， 还 将 支持 目 定 义 的 资源 类 型 。 


2. 资 源 的 配置 范围 管理 (LimitRange) 


默认 情况 下 ，Kubernetes 的 Pod 会 以 无 限制 的 CPU 和 内 存 运行 。 这 


也 就 意味 着 Kubernetes 系 统 中 任何 的 Pod 都 可 以 使 用 其 所 在 节点 上 的 所 
有 可 用 的 CPU 和 内 存 。 通 过 配置 Pod 的 计算 资源 Requests 和 Limits， 我 
们 可 以 限制 Pod 的 资源 使 用 ， 但 对 于 Kubernetes 集 群 管理 员 而 言 ， 配 置 
每 一 个 Pod 的 Requests 和 Limits 是 烦琐 旦 限制 性 过 强 的 。 更 多 的 时 候 ， 

我 们 需要 的 是 对 集群 内 Request 和 Limits 的 配置 做 一 个 全 局 的 统一 的 限 


制 。 


利 见 的 配置 场景 如 下 。 


集群 中 的 每 个 节点 有 2GB 内 存 ， 集 群 管理 员 不 布 望 任何 Pod 申 请 超 
过 2GB 的 内 存 : 因为 整个 集群 中 没有 任何 节点 能 满足 超过 2GB 内 
存 的 请 求 。 如 采 某 个 Pod 的 内 存 配 置 超过 2GB， 那 么 该 Pod 将 永远 
都 无 法 锌 调度 到 任何 斑点 上 执行 。 为 了 防止 这 种 情况 的 发 生 ， 集 
群 管理 员 布 望 能 在 系统 管理 功能 中 设置 禁止 Pod 申 请 超过 2GB 内 
存 。 

集群 由 同一 个 组 织 中 的 两 个 团队 共有 享 ， 各 目 分 别 用 来 运行 生产 环 
境 和 开发 环境 。 生 产 环境 最 多 可 以 使 用 8GB 内 存 ， 而 开发 环境 最 
多 可 以 使 用 512MB 内 存 。 集群 管理 员 希 望 通过 为 这 两 个 环境 创建 
不 同 的 命名 空间 (namespace) 并 为 每 个 命名 空间 设置 不 同 的 限制 
来 满足 这 个 需求 。 

用 户 创建 Pod 时 使 用 的 资源 可 能 会 刚好 比 整 个 机 右 资 源 的 上 限 稍 
小 一 点 ， 而 恰好 剩 下 的 资源 大 小 非常 砷 的 : 不 足以 运行 其 他 任务 


但 整个 集群 加 起 来 又 非常 浪费 。 因 此 ， 集 群 管理 员 和 希望 设置 每 个 
Pod 必 须 至 少 使 用 集群 平均 资源 值 《CPU 和 内 存 ) 的 20%， 这 样 集 
群 能 够 提供 更 好 的 资源 一 致 性 的 调度 ， 从 而 减少 了 资源 浪费 。 


针对 这 些 需 求 ，Kubernetes 提 供 了 LimitRange 机 制 对 Pod 和 容 屁 的 
Requests 和 Limits 配 置 进一步 做 出 限制 。 在 下 面 的 示例 中 ， 将 说 明 如 何 
将 LimitsRange 应 用 到 一 个 Kubernetes 的 命名 空间 (namespace) 中 ， 然 
后 说 明 LimitRange 的 几 种 限制 方式 ， 比 如 最 大 及 最 小 范围 、Requests 和 
Limits 的 默认 值 、Limits 与 Requests 最 大 比例 上 限 等 。 


下 面 通过 LimitRange 的 设置 和 应 用 对 其 进行 说 明 。 
1) 创建 一 个 namespace 
创建 一 个 名 为 limit-example 的 namespace: 


$ kubectl create namespace limit-example 


namespace "limit-example" created 


2) Jjnamespaceix E LimitRange 
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limits.yaml 配 置 文件 ， 内 容 如 下 : 


apiVersion: vi 
kind: LimitRange 
metadata: 

name: mylimits 


spec: 


limits: 
- max: 
cpu: "4" 
memory: 2G1 
min: 
cpu: 200m 
memory: 6Mi 
maxLimitRequestRatio: 
cpu: 3 
memory: 2 
type: Pod 
- default: 
cpu: 300m 
memory: 200Mi 
defaultRequest: 
cpu: 200m 
memory: 100Mi 
max: 
cpu: "2" 
memory: 1Gi 
min: 
cpu: 100m 
memory: 3Mi 
maxLimitRequestRatio: 
cpu: 5 
memory: 4 


type: Container 


创建 该 LimitRange: 


$ kubectl create 


example 


-f limits.yaml 


- namespace-limit- 


limitrange "mylimits" created 


查看 namespacelimit-example 中 的 LimitRange: 


$ kubectl describe limits mylimits --namespace=limit - 


example 
Name: mylimits 
Namespace: limit-example 
Type Resource 
Request Default Limit 
Pod cpu 
- 3 
Pod memory 
- 2 


Container cpu 


Container memory 


Min Max Default 


Max Limit/Request Ratio 


6Mi 2Gi E 
100m 2 


200m300m 


3Mi 16i 100Mi200Mi 


下 面 解释 一 下 LimitRange 中 各 项 配置 的 意义 和 特点 。 


(1) 不 论 是 CPU 还 是 内 存 ， 在 LimitRange 中 ，Pod 和 Container 都 


可 以 设置 Min、Max 和 Max Limit/Requests Ratio 这 三 种 参数 。Container 
还 可 以 设置 Default Request 和 Default Limit 这 两 种 参数 ， 而 Pod 不 能 设置 
Default Request 和 Default Limit ° 


(2) 对 Pod 和 Container 的 五 种 参数 的 解释 如 下 。 


Container 的 Min 《上 面 的 100m 和 3Mi) 是 Pod 中 所 有 容器 的 
Requests 值 的 下 限 ; Container 的 Max (上 面 的 2 和 1Gi) 是 Pod 中 所 
有 容器 的 Limits 值 的 上 限 ; Container 的 Default Request (上 面 的 
200m 和 100Mi) 是 Pod 中 所 有 未 指定 Requests 值 的 容器 的 默认 
Requests 值 ;，Container 的 Default Limit (上 面 的 300m 和 200Mi) 是 
Pod 中 所 有 未 指定 Limits 值 的 容 絮 的 默认 Limits 值 。 对 于 同一 资源 
类 型 ， 这 4 个 参数 必须 满足 以 下 关系 : Min<Default 
Request<Default Limit<Max ° 

Pod 的 Min (上 面 的 200m 和 6Mi) 是 Pod 中 所 有 容器 的 Requests 值 的 
总 和 的 下 限 ; Pod 的 Max (上 面 的 4 和 2Gi) 是 Pod 中 所 有 容器 的 
Limits 值 的 总 和 的 上 限 。 当 容器 未 指定 Requests 值 或 者 Limits 值 
时 ， 将 使 用 Container 的 Default Request 值 或 者 Default Limit 值 。 
Container 的 Max Limit/Requests Ratio (上 面 的 5 和 4) 限制 了 Pod 中 
所 有 容器 的 Limits 值 与 Requests 值 的 比例 上 限 ; 而 Pod 的 Max 
Limit/Requests Ratio (上 面 的 3 和 2) 限制 了 Pod 中 所 有 容器 的 
Limits 值 总 和 与 Requests 值 总 和 的 比例 上 限 。 


(3) 如 果 设 置 了 Container 的 Max， 那 么 对 于 该 类 资源 而 言 ， 整 个 


集群 中 的 所 有 容器 都 必须 设置 Limits， 否 则 将 无 法 成 功 创建 。Pod 内 的 
容器 未 配置 Limits 时 ， 将 使 用 Default Limit 的 值 (本 例 中 的 300m CPU 
和 200Mi 内 存 ) ， 而 如 果 Default 也 未 配置 则 无 法 成 功 创建 。 


(4) 如 果 设 置 了 Container 的 Min， 那 么 对 于 该 类 资源 而 言 ， 整 个 
进 群 中 的 所 有 容器 都 必须 设置 Requests。 如 果 创 建 Pod 的 容 絮 时 未 配置 
该 类 资源 的 Requests ， 那 么 创建 过 程 会 报 验证 错误 。Pod 里 容 属 的 
Redquests 在 未 配置 时 ， 可 以 使 用 默认 值 defaultRequest (本 例 中 的 200m 
CPU 和 100Mi 内 存 ) ; 如 果 未 配置 而 又 没有 defaultRequest， 那 么 会 默 
WAST AA Limits; WMR Limits REX, MARSIT ° 


(5) 对 于 任意 一 个 Pod 而 言 ， 该 Pod 中 所 有 容器 的 Requests 总 和 必 
须 大 于 或 等 于 6Mi， 而 且 所 有 容器 的 Limits 总 和 必须 小 于 或 等 于 1Gi 
同样 ， 所 有 容器 的 CPU Requests 总 和 必须 大 于 或 等 于 200m， 而 且 所 有 
tas JCPU Limits 总 和 必须 小 于 或 等 于 2 。 


(6) Pod 里 任何 容器 的 Limits 与 Requests 的 比例 不 能 超过 Container 
的 Max Limit/Requests Ratio; Pod 里 所 有 容器 的 Limits 总 和 与 Requests 的 
总 和 的 比例 不 能 超过 Pod 的 Max Limit/Requests Ratio ° 


3) 创建 Pod 时 触发 LimitRange 限 制 
最 后 ， 让 我 们 看 看 LimitRange 生 效 时 对 容 需 的 资源 限制 效果 。 


命名 空间 中 的 限制 (LimitRange) 只 会 在 Pod 创 建 或 者 更 新 的 时 候 
执行 检查 。 如 有 果 手 动 修改 限制 (LimitRange) 为 一 个 新 的 值 ， 那 么 这 
个 新 的 值 不 会 去 检查 或 限制 之 前 已 经 在 该 命名 空间 中 创建 好 的 Pod 。 


如 果 用 户 创建 Pod 时 ， 配 置 的 资源 值 (CPU 或 者 内 存 ) 超过 了 
LimitRange 的 限制 ， 那 么 该 创建 过 程 会 报错 ， 在 错误 信息 中 会 说 明 详 
细 的 错误 原因 o 


下 面 通过 创建 一 个 单 容器 Pod 来 展示 默认 限制 是 如 何 配置 到 Pod 上 


$ kubectl run nginx --image=nginx --replicas=1 -- 
namespace=limit-example 


deployment "nginx" created 


查看 已 创建 的 Pod: 


$ kubectl get pods --namespace-limit-example 
NAME READY STATUS 
RESTARTS AGE 
nginx - 2040093540 -s8vzu 1/1 Running 0 


11s 


查看 该 Pod 的 resources 相 关 信 息 : 


$ kubectl get pods nginx-2040093540-s8vzu -- 
namespace=limit-example -o yaml | grep resources -C 8 
resourceVersion: "57" 
selfLink: /api/vi1/namespaces/limit- 
example/pods/nginx-2040093540-ivimu 
uid: 67b20741-f53b-11e5 -b066 -64510658e388 
spec: 
containers: 
- image: nginx 


imagePullPolicy: Always 


name: nginx 
resources: 
limits: 
cpu: 300m 
memory: 200Mi 
requests: 
cpu: 200m 
memory: 100Mi 
terminationMessagePath: /dev/termination-log 


volumeMounts: 


由 于 该 Pod 未 配置 资源 Requests # Limits ， 所 以 使 用 了 
namespacelimit-example 中 的 默认 CPU 和 内 存 定 义 的 Requests 和 Limits 
值 。 


下 面 创建 一 个 超出 资源 限制 的 Pod (使 用 3CPU) 


invalid-pod.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 

name: invalid-pod 
spec: 

containers: 

- name: kubernetes-serve-hostname 

image: gcr.io/google containers/serve hostname 


resources: 


limits: 
cpu: "3" 


memory: 100Mi 


创建 该 Pod， 可 以 看 到 系统 报错 了 ， 并 且 提 供 了 错误 原因 为 超过 


了 限制 。 


$ kubectl create -f  invalid-pod.yaml  -- 
namespace=limit-example 
Error from server: error when creating "invalid- 
pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu 
usage per Pod is 2, but limit is 3., Maximum cpu usage per 


Container is 2, but limit is 3.] 


接 下 来 的 例子 展示 了 LimitRange 对 maxLimitRequestRatio 的 限制 : 


limit-test-nginx.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 

name: limit-test-nginx 

labels: 

name: limit-test-nginx 

spec: 

containers: 

- name: limit-test-nginx 


image: nginx 


resources: 
limits: 
cpu: "1" 
memory: 512Mi 
requests: 
cpu: "0.8" 


memory: 250Mi 


由 于 limit-test-nginx 这 个 Pod 的 全 部 内 存 Limits 总 和 与 Requests 总 和 
的 比例 为 512:250 ， 大 于 LimitRange 中 定义 的 Pod 的 内 存 
maxLimitRequestRatio 值 2， 因 此 创建 会 失败 : 


$ kubectl create -f  limit-test-nginx.yaml -- 
namespace-limit-example 
Error from server: error when creating "limit-test- 
nginx.yaml": pods "limit-test-nginx" is forbidden: [memory 
max limit to request ratio per Pod is 2, but provided ratio 


is 2.048000.] 


下 面 的 例子 为 满足 LimitRange 限 制 的 Pod: 


valid-pod.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 

name: valid-pod 


labels: 


name: valid-pod 
spec: 
containers: 
- name: kubernetes-serve-hostname 
image: gcr.io/google containers/serve hostname 
resources: 
limits: 
cpu: "1" 


memory: 512Mi 


创建 Pod 将 会 成 功 : 


$ kubectl create -f valid-pod.yaml --namespace-limit- 
example 


pod "valid-pod" created 


查看 该 Pod 的 资源 信息 : 


$ kubectl get pods valid-pod --namespace=limit-example 
-o yaml | grep -C 6 resources 
uid: 3bibfd7a-f53c-11e5-b066 -64510658e388 
spec: 
containers: 
- image: gcr.io/google containers/serve hostname 
imagePullPolicy: Always 
name: kubernetes-serve-hostname 


resources: 


limits: 
cpu: "1" 
memory: 512Mi 
requests: 
cpu: "1" 


memory: 512Mi 


可 以 看 到 该 Pod 配 置 了 明确 的 Limits 和 Requests， 因 此 该 Pod 不 会 使 
用 namespacelimit-example 中 定义 的 default 和 defaultRequest ° 


需要 注意 的 是 ，CPU Limits 强 制 配置 这 个 选项 在 Kubernetes 集 群 中 
默认 是 开启 的 ;除非 集群 管理 员 在 部 署 kubelet 时 ， 通 过 设置 参数 --cpu- 
cfs-quota=false 来 关闭 该 限制 : 


$ kubelet --help 
Usage of kubelet 


--cpu-cfs-quota[-true]: Enable CPU CFS quota 
enforcement for containers that specify CPU limits 


$ kubelet --cpu-cfs-quota=false ... 
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Limits 做 限制 ,那么 可 以 通过 配置 Kubemetes 的 命名 空间 
(namespace) 上 的 LimitRange (资源 限制 区 间 ) 来 达到 该 目的 。 在 
Kubernetes 集 群 中 ， 如 果 Pod 没 有 显 式 定义 Limits 和 Requests HIS A 
Kubermetes 系 统 会 将 该 Pod 所 在 的 命名 空间 中 定义 的 LimitRange 的 
default 和 defaultRequests 配 置 到 该 Pod 上 。 


3. 资源 的 服务 质量 管理 (ResourceQoS) 


本 六 对 Kubernetes 如 何 根 据 Pod 的 Requests 和 Limits 配 置 来 实现 针对 
Pod 的 不 同 级 别 的 资源 服务 质量 控制 (QoS) 进行 说 明 。 


在 Kubernetes 的 资源 QoS 体系 中 ， 需 要 保证 高 可 靠 性 的 Pod 可 以 申 
请 可 靠 资 源 ， 而 一 些 不 需要 高 可 靠 性 的 Pod 可 以 申请 可 靠 性 较 低 或 者 
不 可 靠 的 资源 。 在 计算 资源 一 节 中 ， 我 们 讲 到 了 容 妖 的 资源 配置 分 为 
Requests 和 Limits， 其 中 Requests 是 Kubernetes 调 度 时 能 为 容 絮 提供 的 完 
全 可 保障 的 资源 量 (最 低 保障 ) ， 而 Limits 是 系统 允许 容器 运行 时 可 
能 使 用 到 的 资源 量 的 上 限 (最 高 上 限 ) 。Pod 级 别 的 资源 配置 是 通过 
计算 Pod 内 所 有 容器 的 资源 配置 的 总 和 得 出 来 的 。 


Kubernetes 中 Pod 的 Requests 和 Limits 资 源 配置 有 如 下 特点 : 如 果 
Pod 配 置 的 Requests 值 等 于 Limits 值 ， 那 么 该 Pod 可 以 获得 的 资源 是 完全 
可 靠 的 ， 而 如 果 Pod 的 Requests 值 小 于 Limits 值 ， 那 么 该 Pod 获 得 的 资源 
可 分 成 两 部 分 : 一 部 分 是 完全 可 对 的 资源 ， 资 源 量 大 小 等 于 Requests 
值 ;， 另 外 一 部 分 是 不 可 靠 的 资源 ， 这 部 分 资源 最 大 等 于 Limits 与 
Requests 的 差额 值 ， 这 份 不 可 靠 的 资源 能 够 申请 到 多 少 ， 则 取决 于 当 
时 主机 上 容器 可 用 资源 的 余 量 。 


通过 这 种 机 制 ，Kubernetes 可 以 实现 节点 资源 的 超 售 (Over 
Subscription) ， 比 如 在 CPU 完 全 充足 的 情况 下 ， 某 机 器 共有 32GiB 内 
存 可 提供 给 容器 使 用 ， 容 器 配置 为 Requests 值 1GiB，Limits 值 为 
2GiB， 那 么 该 机 器 上 最 多 可 以 同时 运行 32 个 容器 ， 每 个 容器 最 多 可 使 
用 2GiB 内 存 ， 如 采 这 些 容器 的 内 存 使 用 峰值 错开 ， 那 么 所 有 容 妖 也 可 
以 一 直 正常 运行 。 


超 售 机 制 能 有 效 地 提高 资源 的 利用 率 ， 同 时 不 会 影响 容器 申请 的 


完全 可 靠 资 源 的 可 靠 性 。 


1) Requests 和 Limits 对 不 同 计算 资源 类 型 的 限制 机 制 


根据 计算 资源 章节 的 内 容 我 们 知道 ， 容 器 的 资源 配置 满足 以 下 两 
个 人 条件 


。 Requests<= 广 点 可 用 资源 。 


e Requests<=Limits ° 


Kubernetes 根 据 Pod 配 置 的 Requests 值 来 调度 Pod，Pod 在 成 功 调度 
之 后 会 得 到 Requests 值 定义 的 资源 来 运行 ， 而 如 果 Pod 所 在 机 器 上 的 资 
源 有 空余 ， 则 Pod 可 以 申请 更 多 的 资源 ， 最 多 不 能 超过 Limits 的 值 。 我 
们 下 面 看 一 下 Requests 和 Limits 针 对 不 同 计算 资 源 类 型 的 限制 机 制 的 差 
异 。 这 种 差异 主要 取决 于 计算 资源 类 型 是 可 压缩 资源 还 是 不 可 压缩 资 
Ui o 


(1) 可 压缩 资源 


e Kubernetes 目 前 文 持 的 可 压缩 资源 是 CPU。 

e Pod 可 以 得 到 Pod 的 Requests 配 置 的 CPU 使 用 量 ， 而 是 否 能 使 用 超 
过 Requests 值 的 部 分 取决 于 系统 的 负载 和 调度 。 不 过 由 于 目前 
Kubernetes 和 Docker 的 CPU 隔 离 机 制 都 是 在 容器 级 别 隔离 的 ， 所 以 
Pod 级 别 的 资源 配置 并 不 能 完全 得 到 保障 ;Pod 级 别 的 cgroups 正 在 
紧 锣 密 喜 地 开发 中 ， 如 果 将 来 3 引入， 就 可 以 确保 Pod 级 别 的 资源 
配置 准确 运行 。 

空 几 CPU 资 源 按照 容 右 Requests 值 的 比例 分 配 。 举 例 说 明 : 容器 A 
的 CPU 配置 为 Requests 1Limits 10, 4 ##BA‘)CPUAC & X request 


2Limits 8，A 和 B 同 时 运行 在 一 个 节点 上 ， 初 始 状 态 下 容器 的 可 用 
CPU 为 3cores， 那 么 A 和 B 恰 好 得 到 它们 的 Requests 中 定义 的 CPU 用 
量 ， 即 1CPU 和 2CPU。 如果 A 和 B 都 需要 更 多 的 CPU 资 源 ， 而 恰好 
此 时 系统 的 其 他 任务 释放 出 1.5CPU， 那 么 这 1.5CPU 将 按照 A 和 B 
的 Requests 值 的 比例 12 分 配给 A 和 B， 即 最 终 A 可 使 用 1.5CPU，B 
可 使 用 3CPU 。 

如 果 Pod 使 用 了 超过 Limits 10 中 配置 的 CPU 用 量 ， 那 么 cgroups 会 对 
Pod 中 的 容器 的 CPU 使 用 进行 限 流 (throttled) ; 如 果 Pod 没 有 配置 
Limits 10， 那 么 Pod 会 尝试 抢占 所 有 空 闪 的 CPU 资 源 (Kubernetes 
从 1.2 版 本 开始 默认 开启 --cpu-cfs-quota， 因 此 默认 情况 下 必须 配置 


Limits) 。 


(2) 不 可 压缩 资源 


Kubernetes 目 前 支持 的 可 压缩 资源 是 内 存 。 

Pod 可 以 得 到 Requests 中 配置 的 内 存 。 如 果 Pod 使 用 的 内 存量 小 于 
它 的 Requests 的 配置 ， 那 么 这 个 Pod 可 以 正常 运行 《除非 出 现 操作 
系统 级 别 的 内 存 不 足 等 严重 问题 ) ; 如 果 Pod 使 用 的 内 存量 超过 
了 它 的 Requests 的 配置 ， 那 么 这 个 Pod 有 可 能 被 Kubernetes“ 杀 
fa”: 比如 Pod A 使 用 了 超过 Requests 而 不 到 Limits 的 内 存量 ， 此 时 
同一 机 如 上 男 外 一 个 Pod B 之 前 只 使 用 了 远 少 于 自己 的 Requests 值 
的 内 存 ， 而 此 时 程序 压力 增 大 ，Pod B 回 系统 申请 的 总 量 不 超过 目 
己 的 Requests 值 的 内 存 ， 那 么 Kubernetes 可 能 会 直接 杀 掉 Pod A; 
另外 一 种 情况 是 Pod A 使 用 了 超过 Requests 而 不 到 Limits 的 内 存 
量 ， 此 时 Kubernetes 将 一 个 新 的 Pod 调 度 到 这 全 机 器 上 ， 新 的 Pod 
需要 使 用 内 存 ， 而 只 有 Pod A 使 用 了 超过 了 自己 的 Requests 值 的 内 
存 ， 那 么 Kubernetes 也 可 能 会 杀 掉 Pod A 来 释放 内 存 资 源 。 


。 如 采 Pod 使 用 的 内 存量 超过 了 它 的 Limits 设 置 ， 那 么 操作 系统 内 核 
会 杀 挥 Pod 所 有 容器 的 所 有 进程 中 使 用 内 存 最 多 的 一 个 ， 直 到 内 
存 不 超过 Limits 为 止 。 


2) 对 调度 策略 的 影响 


Kubermnetes 的 kubelet 通 过 计算 Pod 中 所 有 容 絮 的 Requests 的 总 和 来 
决定 对 Pod 的 调度 。 

不 管 是 CPU 还 是 内 存 ，Kubernetes 调 度 器 和 kubelet 都 会 确保 节点 上 
所 有 Pod 的 Requests 的 总 和 不 会 超过 该 节点 上 可 分 配给 容 絮 使 用 的 
资源 容量 上 限 。 


3) 服务 质量 等 级 (QoS Classes) 


在 一 个 超 用 (Over Committed, BUA asLimits AIA TARAS 
HR) AST, HP Aas i Veo A BES SRE ASIN UR, A 
终 可 能 会 导致 部 分 容器 被 * 杀 掉 ”。 在 这 种 情况 下 ， 我 们 当然 会 希望 优 
先 “ 杀 掉 ” 那 些 不 太 重 要 的 容 右 ， 那 么 如 何 衡量 重要 程度 呢 ?Kubernetes 
将 容器 划分 成 3 个 QoS 等 级 : Guaranteed (完全 可 靠 的 ) ` Burstable 
(弹性 波动 、 较 可 靠 的 ) 和 Best-Effort (尽力 而 为 、 不 太 可 靠 的 ) ， 这 
三 种 优先 级 依次 递减 ， 如 图 5.4 所 示 。 


Burstable S 
Best Effort e 


5.4 QoS 等 级 和 优先 级 的 关系 


从 理论 上 来 说 ，QoS 级 别 应 该 作为 一 个 单独 的 参数 来 提供 API， 并 
由 用 户 对 Pod 进 行 配置 ， 这 种 配置 应 该 与 Requests 和 Limits 无 天。 但 在 
当前 版 本 的 Kubernetes 的 设计 中 ， 为 了 简化 模式 及 避免 引入 大 多 的 复 
杂 性 ，QoSs 级 别 直接 由 Requests 和 Limits 来 定义 。 在 Kubernetes 中 容器 
的 QoS 级 别 等 于 容器 所 在 Pod 的 QoS 级 别 ， 而 Kubernetes 的 资源 配置 定 
义 了 Pod 的 三 种 QoS 级 别 ， 如 下 所 述 。 


1) Guaranteed 《完全 可 靠 的 ) 


如 果 Pod 中 的 所 有 容器 对 所 有 资源 类 型 都 定义 了 Limits 和 
Requests， 并 且 所 有 容器 的 Limits 值 都 和 Requests 值 全 部 相等 〈 且 都 不 
为 0) ， 那 么 该 Pod 的 QoS 级 别 台 是 Guaranteed。 注 意 : 在 这 种 情况 下 ， 
as AT LAAN FE X. Requests, ， 因 为 Requests 值 在 未 定义 的 时 候 默 认 等 于 


Limits ° 


下 面 这 两 个 例子 中 定义 的 Pod QoS I it Guaranteed: 


containers: 
name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
name: bar 
resources: 
limits: 
cpu: 100m 


memory: 100Mi 


在 上 面 的 例子 中 未 定义 Redquests 值 ， 所 以 其 默认 等 于 Limits 值 。 而 
下 面 这 个 例子 中 定义 的 Requests 和 Limits 的 值 完全 相同 : 


containers: 
name: foo 
resources: 

limits: 
cpu: 10m 
memory: 1Gi 

requests: 
cpu: 10m 
memory: 1Gi 


name: bar 


resources: 
limits: 
Cpu: 100m 
memory: 100Mi 
requests: 
cpu: 10m 


memory: 1Gi 


2) Best-Effort (RAMA ^ AACE] SEY) 


如 果 Pod 中 所 有 容器 都 未 定义 资源 配置 (Requests Fl Limits #h R XE 
X) ， 那 么 该 Pod 的 QoS 级 别 就 是 Best-Effort 。 


例如 下 面 这 个 Pod 定 义 : 


containers: 
name: foo 
resources: 
name: bar 


resources: 


3) Burstable 〈 弹 性 波动 、 较 可 靠 的 ) 


当 一 个 Pod 既 不 是 Guaranteed 级 别 的 ， 也 不 是 Best-Effort 级 别 的 
时 ， 该 Pod 的 QoS 级 别 融 是 Burstable。Burstable 级 别 的 Pod 包 括 两 种 情 
况 。 第 1 种 情况 是 : Pod 中 的 一 部 分 容 絮 在 一 种 或 多 种 资源 类 型 的 资源 
配置 中 ， 定 义 了 Requests 值 和 Limits 值 (都 不 为 0);” ， 且 Requests 值 小 于 
Limits E; 第 2 种 情况 是 : Pod 中 的 一 部 分 容器 未 定义 资源 配置 


(Requests 和 Limits 都 未 定义 ) 9 JERR: Aas RE X Limitsh|, Limitsfü 
默认 等 于 节点 资源 容量 上 限 。 


下 面 几 个 例子 中 的 Pod 的 QoS 等 级 都 是 Burstable。 


(1) 容器 foo 的 CPU Requests 不 等 于 Limits: 


containers: 
name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
requests: 
cpu: 5m 
memory: 1Gi 
name: bar 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
requests: 


cpu: 10m 


memory: 1Gi 


(2) 容器 bar 未 定义 资源 配置 而 容器 foo 定 义 了 资源 配置 : 


containers: 


name: foo 
resources: 
limits: 
cpu: 10m 
memory: 1Gi 
requests: 
cpu: 10m 
memory: 1Gi 
name: bar 


(3) 容器 foo 未 定义 CPU， 而 容器 bar 未 定义 内 存 : 


containers: 
name: foo 
resources: 
limits: 
memory: 1Gi 
name: bar 
resources: 
limits: 


cpu: 100m 


(4) 容器 bar 示 定义 资源 配置 ， 而 容器 foo 未 定义 Limits 值 : 


containers: 


name: foo 


resources: 
requests: 
cpu: 10m 
memory: 1Gi 


name: bar 


4) Kubernetes QoS 的 工作 特点 


Pod 的 CPU Requests 无 法 得 到 满足 (比如 市 点 的 系统 级 任务 占用 过 
多 的 CPU 导致 无 法 分 配给 足够 的 CPU 给 容器 使 用 ) 时 ， 容 器 得 到 的 
CPU 会 被 压缩 限 流 。 


内 存 由 于 是 不 可 压缩 资源 ， 所 以 针对 内 存 资源 紧缺 的 情况 ， 将 按 
照 以 下 逻辑 进行 处 理 。 


(1) Best-Effort Pod 的 优先 级 最 低 ， 这 类 Pod 中 运行 的 进程 会 在 系 
统 内 存 紧缺 时 被 第 一 优先 “ 杀 死 ”。 当 然 ， 从 另外 一 个 角度 来 看 ，Best- 
Effort Pod 由 于 没有 设置 资源 Limits， 所 以 在 资源 充足 的 时 候 ， 它 们 可 
以 充分 地 使 用 所 有 的 内 置 资 源 。 


(2) Burstable Pod 的 优先 级 居中 ， 这 类 Pod 初 始 时 会 分 配 较 少 的 

可 靠 资源 ， 但 可 以 按 需 申请 更 多 的 资源 。 当 然 ， 如 果 整 个 系统 内 存 紧 

缺 ， 而 又 没有 Best-Effort 容 妖 可 以 被 “ 杀 死 ”以 释放 资源 ， 则 这 类 Pod 中 
的 进程 可 能 会 被 “ 杀 死 ”。 


(3) Guaranteed Pod 的 优先 级 最 高 ， 而 且 一 般 情 况 下 这 类 Pod 只 
不 超过 其 资源 Limits 的 限制 就 不 会 被“ 杀 死 *”。 当然 ， et si 
紧缺 ， 而 义 没 有 其 他 更 低 优先 级 的 容器 可 以 被 “ 杀 死 ”以 释放 资源 ， 
类 Pod 中 的 进程 也 可 能 会 被 “杀人 死 ”。 


5) OOM 计 分 系统 
OOM (Out Of Memory) 计 分 规则 包括 如 下 内 容 。 


OOM 计 分 是 一 个 进程 消耗 内 存在 系统 中 占 的 百分比 中 不 含 百 分 号 
的 数字 的 值 乘 以 10 的 结果 ， 这 个 结果 是 进程 OOM 基 础 分 ， 将 进程 
OOM 基础 分 的 分 值 再 加 上 这 个 进程 的 OOM 分 数 调整 值 
OOM_SCORE_ADJ 的 值 作为 进程 OOM 最 终 分 值 〈 除 root 启 动 的 进 
程 外 ) 。 在 系统 发 生 OOM 时 ，OOM Killer 会 优先 杀 掉 OOM 计 分 
更 高 的 进程 。 

进程 的 OOM 计 分 的 基本 分 数值 范围 是 0 一 1000， 如 果 A 进 程 的 调 
整 值 OOM_SCORE_ADJ 减 去 B 进 程 的 调整 值 的 结 末 大 于 1000， 那 
么 A 进 程 的 OOM 计 分 最 终 值 必然 大 于 B 进 程 ，A 进 程 会 比 B 进 程 优 
不 论调 整 值 OOM_SCORE_ADJ 为 多 少 ， 任 何 进 程 的 最 终 分 值 范 
+H, 0~1000 ° 


在 Kubernetes， 不 同 QoS 的 OOM 计 分 调整 值 规则 如 表 5.1 所 示 。 


表 5.1 不 同 QoS 的 OOM 计 分 调整 值 


Qos 等 级 oom_score_adj 
Guaranteed -998 
BestEffort 1000 


Burstable min(max(2, 1000 - (1000 * memoryRequestBytes) / 


machineMemoryCapacityBytes). 999) 


Best-effort Podi OOM SCORE. ADJJ8| E [£i 731000, Witt Best- 
effort Pod 中 的 容器 里 面 的 所 有 进程 的 OOM 最 终 分 肯定 是 1000。 


Guaranteed Pod i& Œ OOM, SCORE ADJ ijl] % (& 73 -998 , [A] itt 
Guaranteed Pod FF EZ gi E TAI AY) PU ERE OOM B28 4] — B 73 08k. 
者 1 (因为 基础 分 不 可 能 为 1000) 
Burstable Pod 规 则 分 情况 说 明 : 如 果 Burstable Pod 的 内 存 Requests 
超过 了 系统 可 用 内 存 的 99.8%， 那 么 这 个 Pod 的 OOM_SCORE_ADJ 
调整 值 固定 为 2， 否 则 ， 设 置 OOM_SCORE_ADJ 调 整 值 为 1000-10 
(内 存 Requests 占 系统 可 用 内 存 的 百分比 的 无 百 分 号 的 数字 部 分 
的 值 ) ， 而 如 果 内 存 Requests 为 0， 那 么 OOM_SCORE_ADJ 调 整 值 
固定 为 999。 这 样 的 规则 能 确保 OOM_SCORE_ADIJ 调 整 值 的 范围 
为 2~999， 而 Burstable Pod 中 所 有 进程 的 OOM 最 终 分 数 苑 围 为 2 一 
1000。Burstable Pod 进 程 的 OOM 最 终 分 数 始终 大 于 Guaranteed Pod 
的 进程 得 分 ， 因 此 它们 会 被 优先 “ 杀 死 *。 如 果 一 个 Burstable Pod 使 
用 的 内 存 比 它 的 内 存 Requests 少 ， 那 么 可 以 肯定 的 是 它 的 所 有 进 
程 的 OOM 最 终 分 数 会 小 于 1000， 此 时 能 确保 它 的 优先 级 高 于 Best- 
effort Pod。 如 果 一 个 Burstable Pod 的 某 个 容器 中 某 个 进程 使 用 的 
内 存 比 容器 的 request 值 高 ， 那 么 这 个 进程 的 OOM 最 终 分 数 会 是 
1000， 否 则 它 的 OOM 最 终 分 会 小 于 1000。 假 设 下 面容 全 中 有 一 个 
占用 内 存 非常 大 的 进程 ， 那 么 当 一 个 使 用 内 存 超 过 其 Requests 的 
Burstable Pod 与 男 外 一 个 使 用 内 存 少 于 其 Requests 的 Burstable Pod 
发 生 内 存 竞 争 冲突 时 ， 前 者 的 进程 会 被 系统 “ 杀 掉 *”。 如 果 一 个 
Burstable Pod 内 部 有 多 个 进程 的 多 个 容器 发 生 内 存 竞争 冲突 ， 那 
么 此 时 OOM 评 分 只 能 作为 参考 ， 不 能 保证 完全 按照 资源 配置 的 定 
义 来 执行 OOM Kill ° 


OOM 还 有 一 些 特殊 的 计 分 规则 ， 如 下 所 壕 。 


e kubelet 进 程 和 Docker 进 程 的 调整 值 OOM_SCORE_ADJ 为 -998。 


。 如 果 配 置 进程 调整 值 0OOM_SCORE_ADJ 为 -999， 那 么 这 类 进程 不 
会 被 OOM Killer“ 杀 掉 ”。 


6) QoS 的 演进 


目前 Kubernetes 基 于 QoS 的 超 用 机 制 日 趋 完 善 ， 但 还 有 一 些 问 题 需 
要 解决 。 


7) 内 存 Swap 的 文 持 


当前 的 QoS 策 略 都 是 假定 主机 不 局 用 内 存 Swap。 如 果 主 机 局 用 了 
Swap， 那 么 上 面 的 QoS 策略 可 能 会 失效 。 举 例 说 明 : 两 个 Guaranteed 
Pod 都 刚好 达到 了 内 存 Limits， 那 么 由 于 内 存 Swap 机 制 ， 它 们 还 可 以 继 
续 申 请 使 用 更 多 的 内 存 。 如 采 Swap 空 间 不 足 ， 那 么 最 终 这 两 个 Pod 中 
的 进程 可 能 会 被 * 杀 掉 ”。 由 于 Kubernetes 和 Docker 疝 不 文 持 内 存 Swap 
空间 的 隔离 机 制 ， 所 以 这 一 功能 暂时 还 未 实现 。 


8) 更 丰富 的 QoS 策略 


当前 的 QoS 策略 都 是 基于 Pod 的 资源 配置 (RequestsflLimits) 来 
定义 的 ， 而 资源 配置 本 续 又 承担 着 对 Pod 资 源 管理 和 限制 的 功能 。 两 
种 不 同 维度 的 功能 使 用 同一 个 参数 来 配置 ， 可 能 会 导致 某 些 复杂 需求 
无 法 满足 ， 比 如 当前 Kubernetes 无 法 文 持 弹性 的 、 高 优先 级 的 Pod。 A 
定义 QoS 优 移 级 能 提供 更 大 的 灵活 性 ， 完 美 地 实现 各 类 需求 ， 但 同时 
会 引入 更 高 的 复杂 性 ， 而 且 过 于 灵活 的 设置 会 给 予 用 户 过 高 的 权限 ， 
对 系统 管理 也 提出 了 更 大 的 挑战 。 


4. 资 源 的 配额 管理 (Resource Quotas) 


如 果 一 个 Kubernetes 集 群 被 多 个 用 户 或 者 多 个 团队 共享 使 用 ， 那 
么 就 需要 考虑 共享 时 对 资源 公平 使 用 的 问题 ， 因 为 某 个 用 户 可 能 会 使 
用 超过 基于 公平 原则 分 配给 其 的 资源 量 。 


资源 配额 (Resource Quotas) 就 是 解决 这 个 问题 的 工具 。 通 过 
ResourceQuota 对 象 ， 我 们 可 以 定义 一 项 资源 配额 ， 这 个 资源 lis 
为 每 一 个 命名 空间 (namespace) 提供 一 个 总 体 的 资源 使 用 的 限制 : 

可 以 限制 命名 空间 中 某 种 类 型 的 对 象 的 总 BH ERR. iu 
空间 中 Pod 可 以 使 用 到 的 计算 资源 的 总 上 限 。 


典型 的 资源 配额 (Resource Quotas) 使 用 方式 如 下 。 


不 同 的 团队 工作 在 不 同 的 命名 空间 下 ， 目 前 这 个 是 非 约 束 性 的 ， 
未 来 版 本 中 可 能 会 通过 ACLs (访问 控制 列表 Access Control List) 
的 方式 来 实现 强制 性 约束 。 

集群 管理 员 为 集群 中 的 每 个 命名 空间 创建 一 个 或 者 多 个 资源 配额 
项 。 

当 用 户 在 命名 空间 中 使 用 资源 (创建 Pod 或 者 Service 等 ) 时 ， 
Kubemetes 的 配额 系统 会 统计 、 监 控 和 检查 资源 用 量 ， 以 确保 使 
用 的 资源 用 量 没有 超过 资 AAC PTAC EL ° 

如 采 创 建 或 者 更 新 应 用 时 ， 资 源 使 用 超过 了 某 项 资源 配额 的 限 
制 ， 那 么 创建 或 者 更 新 的 请 求 会 报错 (HTTP 403Forbidden) ， 错 
误 信 息 给 出 详细 的 出 错 原因 说 明 。 

如 果 命 名 空间 中 的 计算 资源 (CPU 和 内 存 ) 的 资源 配额 启用 ， 那 
么 用 户 必 须 为 相应 的 资源 类 型 设置 Requests 或 Limits; 否则 配额 系 
统 可 能 会 直接 拒绝 Pod 的 创建 。 这 里 可 以 使 用 LimitRange 机 制 来 为 
没有 配置 资源 的 Pod 提 供 默 认 资 源 配置 。 


下 面 的 例子 展示 了 一 个 非常 适合 使 用 资源 配额 来 做 资源 控制 管理 
的 场景 。 


。 集群 共 有 32GB 内 存 和 16CPU， 两 个 小 组 ，A 小 组 使 用 20GB 内 存 和 
10CPU ，B 小 组 使 用 10GB 内 存 和 2CPU， 剩 下 的 2GB 内 存 和 2CPU 
作为 预 留 。 

在 名 为 testing 的 命名 空间 中 ， 限 制 使 用 1CPU 和 1GB 内 存 ; 在 名 为 
production 的 命名 空间 中 ， 资 源 使 用 不 受 限 制 。 


在 使 用 资源 配额 时 ， 需 要 注意 以 下 两 点 。 


ANAS EE TOAD AT FER ANT di fin Bux E PR AC AMA, Jb 
么 可 能 会 导致 货源 竞争 。 资 源 竞 争 时 ，Kubernetes 系 统 使 用 先 到 
完 得 的 原则 。 

不 管 是 资源 竞争 还 是 配额 的 修改 都 不 会 影响 到 已 经 创建 的 资源 使 
用 对 象 。 


) 在 Master 中 开局 资源 配额 选 型 


资源 配额 可 以 通过 在 kube-apiserver 的 --admission-control= 参 数值 中 
添加 ResourceQuota 参 er 。 如果 某 个 命名 空间 的 定义 中 存在 
ue nds 那么 对 于 该 命名 空间 而 言 ， 资 源 配 额 就 是 开启 的 。 

命名 空间 可 以 有 多 个 ResourceQuota 配 置 项 。 


(1) 计算 资源 配额 (Compute Resource Quota) 


资源 配额 可 以 限制 一 个 命名 空间 中 所 有 Pod 的 计算 资源 的 总 和 。 
表 5.2 列 出 了 目前 Kubernetes 资 源 配额 文 持 限制 的 计算 资源 类 型 。 


表 5.2 ResourceQuota 的 计算 资源 类 型 


资源 名 称 说 Bj 
cpu 所 有 非 终 止 状态 的 Pod, CPU Requests 的 总 和 不 能 超过 该 值 
limits.cpu 所 有 非 终 止 状态 的 Pod, CPU Limits 的 总 和 不 能 超过 该 值 
limits. memory 所 有 非 终 止 状态 的 Pod， 内 存 Limits 的 总 和 不 能 超过 该 值 
memory 所 有 非 终 止 状态 的 Pod， 内 存 Requests 的 总 和 不 能 超过 该 值 
requests.cpu 所 有 非 终 止 状态 的 Pod，CPU Requests 的 总 和 不 能 超过 该 值 
requests.memory 所 有 非 终 止 状态 的 Pod， 内 存 Requests 的 总 和 不 能 超过 该 值 


(2) 对 象 数量 配额 (Object Count Quota) 


指定 类 型 的 对 象 数 量 可 以 被 限制 。 表 5.3 列 出 了 Kubernetes 资 源 配 
额 文 持 限制 对 象 数量 的 对 象 类 型 。 


表 5.3 ”ResourceQuota 的 对 象 类 型 


资源 名 称 说 AA 
configmaps :该 命名 空间 中 ， 能 存在 的 ConfigMap 的 总 数 上 限 
persistentvolumeclaims :该 命名 空间 中 ， 能 存在 的 持久 卷 的 总 数 上 限 
pods 在 该 命名 空间 中 ,能 存在 的 非 终止 状态 Pod 的 总 数 上 限 。Pod 终止 状态 等 价 于 
se 状态 值 为 Failed 或 者 Succeed is true 
replicationcontrollers :该 命名 空间 中 ， 能 存在 的 RC 的 总 数 上 限 


resourcequotas :该 命名 空间 中 ， 能 存在 的 资源 配额 项 CResourcesQuota) 的 总 数 上 限 
services :该 命名 空间 中 ， 能 存在 的 service 的 总 数 上 限 

services.loadbalancers Ei 空间 中 ， 能 存在 的 负载 均衡 (LoadBalancer) 的 总 数 上 限 
services.nodeports 在 该 命名 空间 中 ， 能 存在 的 NodePort 的 总 数 上 限 

secrets i 空间 中 ， 能 存在 的 Secret 的 总 数 上 限 


例如 我 们 可 以 通过 资源 配额 来 限制 命名 空间 中 能 创建 的 Pod 的 最 
大 数量 。 这 种 设置 可 以 防止 某 些 用 户 大 量 创 建 Pod 而 迅速 耗 尽 整个 集 
群 的 Pod IP 和 计算 资源 。 


2) 配 知 的 作用 域 (Quota Scopes) 


每 项 资源 配额 都 可 以 单独 配置 一 组 作用 域 ， 配置 了 作用 域 的 资源 
配额 只 会 对 符合 其 作用 域 的 资源 使 用 进行 计量 和 限制 ， 作 用 域 殉 围 内 


的 且 超 过 了 资源 配额 的 请 求 都 会 报 验 证 错 。 表 5.4 列 出 了 ResourceQuota 
的 4 种 作用 域 。 


表 5.4 ResourceQuota 的 作用 域 


fe 用 域 说 AA 


Terminating 多 配 所 有 spec.activeDeadlineSeconds >= 0 的 Pod 


NotTerminating 匹配 所 有 spec.activeDeadlineSeconds 是 nil 的 Pod 


BestEffort 匹配 所 有 QoS 为 Best-Effort 的 Pod 
NotBestEffort 匹配 所 有 QoS 不 是 Best-Effort 的 Pod 


其 中 ，BestEffort 作 用 域 可 以 限定 资源 配额 来 追踪 pods 资 源 的 使 
用 ，Terminating、NotTerminating 和 NotBestEffort 这 三 种 作用 域 可 以 限 
定 资 源 配 额 来 追踪 以 下 资源 的 使 用 。 


e cpu 
e limits.cpu 

e limits.memory 
e memory 

e pods 

e requests.cpu 


e requests.memory 


3) 在 资源 配额 (ResourceQuota) 中 设置 Requests 和 Limits 


资源 配额 也 可 以 设置 Requests 和 Limits。 


如 果 资 源 配 额 中 指定 了 requests.cpu 或 requests.memory， 那 么 它 会 
强制 要 求 每 一 个 容器 都 必须 配置 自己 的 CPU Requests 或 CPU Limits 
(可 使 用 LimitRange 提 供 的 默认 值 ) 。 


同 理 ， 如 果 资 源 配额 中 指定 了 limits.cpu 或 limits.memory， 那 么 它 
也 会 强制 要 求 每 一 个 容器 都 必须 配置 自己 的 内 存 Requests 或 内 存 Limits 
(可 使 用 LimitRange 提 供 的 默认 值 ) 。 


4) 资源 配额 (ResourceQuota) 的 定义 
下 面 通过 几 个 例子 对 资源 配额 进行 设置 和 应 用 。 


与 LimitRange 相 似 ，ResourceQuota 也 设置 在 namespace 中 。 创 建 名 


Amy spacet*Jnamespace: 


$ kubectl create namespace myspace 


namespace "myspace" created 


创建 ResourceQuota 配 置 文件 compute-resources.yaml， 用 于 设置 计 
算 资 源 的 配额 ;: 


apiVersion: vi 
kind: ResourceQuota 
metadata: 
name: compute-resources 
spec: 
hard: 
pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 


limits.memory: 2Gi 


创建 该 项 资源 配额 : 


$ kubectl create -f compute-resources.yaml -- 
namespace=myspace 


resourcequota "compute-resources" created 


创建 男 一 个 名 为 object-counts.yaml 的 文件 ， 用 于 设置 对 象 数量 的 
配额 : 


apiVersion: vi 
kind: ResourceQuota 
metadata: 
name: object-counts 
spec: 
hard: 
configmaps: "10" 
persistentvolumeclaims: "4" 
replicationcontrollers: "20" 
secrets: "10" 
services: "10" 


services.loadbalancers: "2" 


创建 该 ResourceQuota: 


$ kubectl create -f  object-counts.yaml  -- 
namespace=myspace 


resourcequota "object-counts" created 


查看 各 ResourceQuota 的 详细 信息 : 


$ kubectl describe quota compute-resources 


namespace=myspace 


Name: compute-resources 
Namespace: myspace 

Resource Used Hard 
limits.cpu 0 2 
limits.memory 0 2G1 

pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi 


$ kubectl describe quota  object-counts 


namespace=myspace 


Name: object-counts 
Namespace: myspace 
Resource Used Hard 
configmaps 0 10 
persistentvolumeclaims 0 4 
replicationcontrollers 0 20 
secrets 1 10 
services 0 10 


services.loadbalancers 0 2 


5) 货源 配额 与 集群 资源 总 量 的 关系 


质 源 配额 与 集群 资源 总 量 是 完全 独立 的 。 资 源 配额 是 通过 绝对 的 
单位 来 配置 的 : 这 也 吏 意 味 着 如 果 集 群 中 新 添加 了 节点 ， 那 么 货源 配 
额 不 会 目 动 更 新 ， 而 该 货源 配额 所 对 应 的 命名 空间 下 对 象 也 不 能 目 动 
地 增加 资源 上 限 。 


在 某 些 情况 下 ， 我 们 可 能 希望 资源 配额 能 文 持 更 复杂 的 策略 ， 如 
下 所 述 。 


。 对 于 不 同 的 租户 ， 按 照 比 例 划 分 整个 集群 的 资源 。 

。 人 允许 每 个 租户 都 能 按照 需要 来 提高 资源 用 量 ， 但 是 有 一 个 较 宽 容 
的 限制 ， 以 防止 意外 的 资源 耗 尽情 况 发 生 。 

。 探测 某 个 命名 空间 的 需求 ， 添 加 物理 广 点 并 扩大 资源 配额 值 。 


这 些 策略 可 以 通过 将 资源 配额 作为 一 个 控制 模块 、 手 动 编写 一 个 
控制 器 (controller) 来 监控 资源 使 用 情况 ， 并 调整 命名 空间 上 的 资源 
配额 的 方式 来 实现 。 


资源 配额 将 整个 集群 中 的 资源 总 量 做 了 一 个 静态 的 划分 ， 但 它 并 
没有 对 集群 中 的 节点 (Node) 做 任何 限制 不 同 命名 空间 中 的 Pod 仍 
然 可 以 运行 到 同一 个 节点 上 。 


5.ResourceQuota 和 LimitRange 实 践 指南 


根据 前 面 对 资 源 管理 的 介绍 ， 这 里 将 通过 一 个 完整 的 例子 来 说 明 
如 何 通 过 资源 配额 和 六 各 源 配置 范围 的 配合 来 控制 一 个 命名 空间 的 资源 
TERI = 


集群 管理 员 根 据 集 群 用 户 数量 来 调整 集群 配置 ， 以 达到 如 下 目 
的 : 能 控制 特定 命名 空间 中 的 资源 使 用 量 ， 最 终 实 现 集群 的 公平 使 用 
和 成 本 的 控制 。 


需要 实现 的 功能 如 下 。 


。 限制 运行 状态 的 Pod 的 计算 资源 用 量 。 

。 限制 持久 存储 卷 的 数量 以 控制 对 存储 的 访问 。 

。 限制 负载 均衡 器 的 数量 以 控制 成 本 。 

。 防止 造 用 网 络 端口 这 类 稀缺 资源 。 

。 提供 默认 的 计算 资源 Requests 以 便于 系统 做 出 更 优化 的 调度 。 


1) 创建 命名 空间 


创建 名 为 quota-example 的 命名 空间 ，namespace.yaml 文 件 的 内 容 
如 下 : 


apiVersion: vi 
kind: Namespace 
metadata: 


name: quota-example 


$ kubectl create -f namespace.yaml 


namespace "quota-example" created 


查看 命名 空间 : 


$ kubectl get namespaces 


NAME STATUS AGE 
default Active 2m 
kube-system Active 2m 
quota-example Active 39s 


2) 设置 限定 对 象 数目 的 资源 配额 


通过 设置 限定 对 象 的 数量 的 资源 配额 ， 可 以 控制 以 下 资源 的 数 


bi 


。 持久 存储 卷 ; 
。 负载 均衡 器 ; 
e NodePort ° 


创建 名 为 object-counts 的 ResourceQuota: 


object-counts.yaml: 
apiVersion: vi 
kind: ResourceQuota 
metadata: 
name: object-counts 
spec: 
hard: 
persistentvolumeclaims: "2" 
services.loadbalancers: "2" 


services.nodeports: "0" 


$ kubectl create -f  object-counts.yaml -- 


namespace=quota-example 


resourcequota "object-counts" created 


配额 系统 会 检测 到 资源 项 配额 的 创建 ， 并 且 将 会 统计 和 限制 该 命 
名 空间 中 的 资源 消耗 。 


$ kubectl describe quota object-counts -- 


namespace=quota-example 


Name: object-counts 
Namespace: quota-example 
Resource Used Hard 
persistentvolumeclaims 0 2 
services.loadbalancers 0 2 
services.nodeports 0 0 


至 此 ， 配 额 系统 会 目 动 阻止 那些 使 资源 用 量 超过 资源 配额 限定 值 
的 请 求 。 


3) 设置 限定 计算 资源 的 资源 配额 


下 面 我 们 再 来 创建 一 项 限定 计算 资源 的 资源 配额 ， 以 限制 该 命名 
空间 中 的 计算 资源 的 使 用 总 量 。 


创建 名 为 compute-resources 的 ResourceQuota: 


apiVersion: v1 
kind: ResourceQuota 
metadata: 
name: compute-resources 
spec: 
hard: 
pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 


limits.memory: 26Gi 


$ kubectl create -f compute-resources.yaml 
namespace=quota-example 


resourcequota "compute-resources" created 


$ kubectl describe quota compute-resources 


namespace=quota-example 


Name: compute-resources 
Namespace: quota-example 
Resource Used Hard 
limits.cpu 0 2 
limits.memory 0 2Gi 


pods 0 4 


requests.cpu 0 1 


requests.memory 0 1Gi 


配额 系统 会 自动 防止 该 命名 空间 下 同时 拥有 超过 4 个 非 “ 终 止 态 ” 的 
Pod。 此 外 ， 由 于 该 项 资源 配额 限制 了 CPU 和 内 存 的 Limits 和 Requests 
的 总 量 ， 因 此 会 强制 要 求 该 命名 空间 下 的 所 有 容器 都 必须 显示 地 定义 
CPU 和 内 存 的 Limits 和 Requests (可 使 用 默认 值 ，Requests 默 认 等 于 


Limits) 。 


4) 配置 默认 Requests 和 Limits 


在 命名 空间 已 经 配置 了 限定 计算 资源 的 资源 配额 的 情况 下 ， 如 果 
尝试 在 该 命名 空间 下 创建 一 个 不 指 走 Requests 和 Limits 的 Pod， 那 么 Pod 
的 创建 可 能 会 失败 。 下 面 是 一 个 失败 的 例子 。 


创建 一 个 Nginx 的 Deployment: 


$ kubectl run nginx --image=nginx --replicas=1 -- 
namespace=quota-example 


deployment "nginx" created 
查看 创建 的 Pod， 会 发 现 Pod 没 有 创建 成 功 : 
$ kubectl get pods --namespace=quota-example 


再 查看 一 下 Deployment 的 详细 信息 : 


$ kubectl describe deployment nginx --namespace=quota- 


example 
Name: 
Namespace: 
CreationTimestamp: 
-0400 
Labels: 
Selector: 
Replicas: 
available | 1 unavailable 


StrategyType: 


MinReadySeconds: 


RollingUpdateStrategy: 


OldReplicaSets: 
NewReplicaSet: 


created) 


nginx 


quota-example 


Mon, 06 Jun 2016 16:11:37 
run=nginx 
run=nginx 
© updated | 1 total | 0 
RollingUpdate 


0 
1 max unavailable, 1 max surge 
«none» 


nginx-3137573019 (0/1 replicas 


本 Deployment Ž iX AJ E — ^ Pod, 但 是 失败 了 ， 查 看 其 中 


ReplicaSet 的 详细 信息 .: 


$ kubectl 
namespace=quota-example 
Name: 
Namespace: 
Image(s): 


Selector: 


describe rs 


nginx-3137573019  -- 


nginx-3137573019 
quota-example 
nginx 


pod-template- 


hash=3137573019, run=nginx 


Labels: pod- template -hash=3137573019 
run=nginx 
Replicas: © current / 1 desired 
Pods Status: © Running / © Waiting / 0 


Succeeded / © Failed 


No volumes. 


Events: 
FirstSeen LastSeen Count From 
SubobjectPath Type Reason Message 
4m 7S 11 {replicaset-controller } 
Warning FailedCreate Error creating: pods  "nginx- 


3137573019-" is forbidden: Failed quota: compute-resources: 
must specify 


limits.cpu, limits.memory, requests.cpu, requests.memory 


可 以 看 到 Pod 创 建 失败 的 原因 : Master 拒 绝 了 这 个 ReplicaSet 创 建 


Pod， 因 为 这 个 Pod 中 没有 指定 CPU 和 内 存 的 Requests 和 Limits ° 


为 了 避免 这 种 失败 ， 我 们 可 以 使 用 LimitRange 来 为 这 个 命名 空间 


下 的 所 有 Pod 提 供 一 个 资源 配置 的 默认 值 。 下 面 的 例子 展示 了 如 何 为 


个 命名 空间 添加 一 个 指定 默认 资源 配置 的 LimitRange ^ 


创建 一 个 名 为 limits 的 LimitRange: 


limits. yaml: 
apiVersion: v1 
kind: LimitRange 
metadata: 
name: limits 
spec: 
limits: 
- default: 
cpu: 200m 
memory: 512Mi 
defaultRequest: 
cpu: 100m 
memory: 256Mi 


type: Container 
$ kubectl create -f limits.yaml 
example 


limitrange "limits" created 


$ kubectl describe limits limits 


example 
Name : limits 
Namespace: quota-example 


Type Resource Min Max 


Default Limit Max Limit/Request Ratio 


- -namespace=quota- 


- -namespace=quota- 


Default Request 


Container memory - - 256M1512M1 - 


Container cpu - - 100m200m - 


LimitRange 创 建成 功 后 ， 用 户 在 该 命名 空间 下 的 创建 未 指定 资源 
配置 的 Pod 的 请 求 时 ， 系 统 会 自动 为 该 Pod 设 置 默认 的 资源 配置 。 


例如 ， 每 个 新 建 的 未 指定 资源 配置 的 Pod 都 等 价 于 使 用 下 面 的 资 
源 配 置 : 


A 


kubectl run nginx \ 

--image=nginx \ 

--replicas=1 \ 
--requests-cpu-100m,memory-256Mi \ 
--limits=cpu=200m,memory=512Mi \ 


- -namespace=quota-example 


至 此 ， 我 们 已 经 为 该 命名 空间 配置 好 了 默认 的 计算 资源 ， 我 们 的 
ReplicaSet 应 该 能 够 创建 Pod 了 。 查 看 一 下 ， 创 建 Pod 成 功 了 : 


$ kubectl get pods --namespace=quota-example 
NAME READY STATUS RESTARTS 
AGE 
nginx -3137573019-fvrig 1/1 Running 0 
6m 


接 下 来 ， 还 可 以 随时 碍 看 资源 配额 的 使 用 情况 : 


$ kubectl describe quota --namespace=quota-example 


Name: compute-resources 
Namespace: quota-example 
Resource Used Hard 
limits.cpu 200m 2 


limits.memory 512Mi 26i 
pods 1 4 
requests.cpu 100m 1 


requests.memory 256Mi 16i 


Name: object-counts 
Namespace: quota-example 
Resource Used Hard 
persistentvolumeclaims 0 2 
services.loadbalancers 0 2 
services.nodeports 0 0 


可 以 看 到 每 个 Pod 创 建 时 都 会 消耗 掉 指 定 的 资源 量 ， 而 这 些 使 用 
量 都 会 被 Kubemetes 准 确 地 跟踪、 监控 和 管理 。 


5) 指定 资源 配额 的 作用 域 


假设 我 们 并 不 想 为 某 个 命名 空间 配置 默认 的 计算 资源 配额 ， 而 是 
希望 限定 在 命名 空间 内 运行 的 QoS 为 BestEffort 的 Pod 总 数 ， 例 如 将 集群 


中 的 部 分 资源 用 来 运行 QoS 为 非 BestEffort 的 服务 ， 而 将 内 置 的 资源 用 
来 运 和 即 可 避免 集群 的 所 有 资源 仅 被 大 量 的 
BestEffort Pod 耗 尽 。 这 可 以 通过 创建 两 个 资源 配额 (ResourceQuota) 


来 实现 。 
首先 创建 一 个 名 为 quota-scopes 的 命名 空间 : 


$ kubectl create namespace quota-scopes 


namespace "quota-scopes" created 


fil] E — ^ 4 W best-effort 的 ResourceQuota , fH Œ Scope 7J 
BestEffort: 


apiVersion: vi 
kind: ResourceQuota 
metadata: 


name: best-effort 


spec: 
hard: 
pods: "10" 
scopes: 
- BestEffort 


$ kubectl create -f  best-effort.yaml -- 


namespace=quota- scopes 


resourcequota "best-effort" created 


再 创建 一 个 名 为 not-bestreffort 的 ResourceQuota 1&8 %E Scope 7J 
NotBestEffort: 


apiVersion: vi 
kind: ResourceQuota 
metadata: 
name: not-best-effort 
spec: 
hard: 
pods: "4" 
requests.cpu: "1" 
requests.memory: 1Gi 
limits.cpu: "2" 
limits.memory: 26Gi 
scopes: 


- NotBestEffort 


$ kubectl create -f  not-best-effort.yaml -- 
namespace=quota- scopes 


resourcequota "not-best-effort" created 


查看 创建 成 功 的 ResourceQuota: 


$ kubectl describe quota --namespace=quota-scopes 
Name: best-effort 
Namespace: quota-scopes 


Scopes: BestEffort 


* Matches all pods that have best effort quality of 


service. 
Resource Used Hard 
pods 0 10 
Name: not-best-effort 
Namespace: quota-scopes 
Scopes: NotBestEffort 


* Matches all pods that do not have best effort 
quality of service. 


Resource Used Hard 


limits.cpu 0 2 
limits.memory 0 26i 
pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi 


之 后 ， 对 于 没有 配置 Requests 的 Pod 将 会 被 名 为 bestreffort 的 
ResourceQuota 所 限制 ;而 配置 了 Requests 的 Pod 会 被 名 为 not-bestreffort 
的 ResourceQuota 所 限制 。 


创建 两 个 Deployment: 


$ kubectl run best-effort-nginx --image=nginx -- 


replicas=8 --namespace=quota-scopes 


deployment "best-effort-nginx" created 


$ kubectl run not-best-effort-nginx \ 
--image-nginx \ 
--replicas-2 \ 
--requests-cpu-100m,memory-256Mi \ 
- -limits-cpu-200m,memory-512Mi \ 
- -namespace=quota-scopes 


deployment "not-best-effort-nginx" created 


名 为 best-effort-nginx 的 Deployment 因为 没有 配置 Requests 和 
Limits ， 所 以 它 的 QoS 级 别 为 BestEffort， 因 此 它 的 创建 过 程 由 best- 
effort 资 源 配额 项 来 限制 ， 而 not-best-effort 资 源 配额 项 不 会 对 它 进 行 限 
til] 。best-effort 资 源 配 额 项 没有 限制 Requests 和 Limits， 因 此 best-effort- 
nginx Deployment 可 以 成 功 地 创建 8 个 Pod。 


名 为 not-best-effort-nginx 的 Deployment 因为 配置 了 Requests 和 
Limits， 且 二 者 不 相等 ， 所 以 它 的 QoS 级 别 为 Burstable， 因 此 它 的 创建 
过 程 由 not-best-effort 资 源 配额 项 来 限制 ， 而 best-effort 资 源 配额 项 不 会 
对 它 进行 限制 。not-best-effort 资 源 配额 项 限制 oo a 
的 总 上 限 not-best-effort-nginx Deployment 并 没有 超过 这 个 上 限 ， 上 所 
以 可 以 成 功 地 创建 两 个 pod。 


查看 已 经 创建 的 Pod: 


$ kubectl get pods --namespace=quota-scopes 
NAME READY 
STATUS RESTARTS AGE 


Running 


Running 


Running 


Running 


Running 


Running 


Running 


Running 


Running 


Running 


best-effort-nginx-3488455095 -2qb41 

0 51s 

best-effort-nginx-3488455095-3go7n 

0 51s 

best-effort-nginx-3488455095-902xg 

0 51s 

best-effort-nginx-3488455095-eyg40 

0 51s 

best-effort-nginx-3488455095-gcs3v 

0 51s 

best-effort-nginx-3488455095-rq8p1 

0 51s 

best-effort -nginx-3488455095 -udhhd 

0 51s 

best-effort-nginx-3488455095-zmk12 

0 51s 
not-best-effort-nginx-2204666826-7s161 

0 23s 
not-best-effort-nginx-2204666826-ke746 


0 23S 


可 以 看 到 10 个 Pod 都 创建 成 功 。 


再 看 一 下 两 个 资源 配额 项 的 使 用 情况 : 


$ kubectl describe quota --namespace=quota-scopes 


Name: best-effort 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


1/1 


Namespace: quota-scopes 
Scopes: BestEffort 


* Matches all pods that have best effort quality of 


service. 
Resource Used Hard 
pods 8 10 
Name: not-best-effort 
Namespace: quota-scopes 
Scopes: NotBestEffort 


* Matches all pods that do not have best effort 


quality of service. 


Resource Used Hard 
limits.cpu 400m 2 
limits.memory 16i 26i 
pods 2 4 
requests.cpu 200m 1 
requests.memory 512Mi 16i 


可 以 看 到 best-effort 资 源 配额 项 已 经 统计 到 T best-effort-nginx 
Deployment 中 创建 的 8 个 Pod 的 资源 使 用 信息 ， 而 not-best-effort 资 源 配 
额 项 也 统计 到 了 not-best-effort-nginx Deployment 中 创建 的 两 个 Pod 的 资 
源 使 用 信息 。 


通过 这 个 例子 我 们 可 以 看 到 : 资源 配额 的 作用 域 (Scopes) 提供 
了 一 种 将 资源 集合 分 割 的 机 制 ， TPO LAR er ra TAB A 
EE b in 28 AI BRR all ZN [e] SAT BOT FR BEY BEAD, RS BEN BED oP 
配 和 限制 提供 更 大 的 灵活 度 和 便利 性 


Kubernetes HF? B5 5t Wit E E By 3E Rl Ae A ss Pod AY Bt YR AC E 

(RequestsflLimits) 。 容 器 的 资源 配置 (Requests 和 Limits) 指定 了 容 

妖 请 求 的 资源 和 容 絮 能 使 用 的 资源 上 限 ， 而 Pod 的 资源 配置 则 是 Pod 中 
所 有 容器 的 资源 配置 总 和 的 上 限 。 


通过 资源 配额 (Resource Quota) 机 制 ， 我 们 可 以 对 命名 空间 下 所 
有 Pod 使 用 资源 的 总 量 进行 限制 ， 也 可 以 对 这 个 命名 空间 中 指定 类 型 
的 对 象 的 数量 进行 限制 。 使 用 作用 域 可 以 让 资源 配额 只 对 符合 特定 范 
围 的 对 象 加 以 限制 ， 因 此 作用 域 (Scopes) 机 制 可 以 使 资源 配额 的 集 
略 更 加 丰富 灵活 。 


如 有 果 我 们 需要 对 用 户 的 Pod 或 容器 的 资源 配置 做 更 多 的 限制 ， 则 
我 们 可 以 使 用 资源 配置 范围 (LimitRange) 来 达到 这 个 目的 。 
LimitRange 可 以 有 效 地 限制 Pod 和 容 絮 的 资源 配置 的 最 大 、 最 小 范围 ， 
也 可 以 限制 pod 和 容 絮 的 Limits 与 Requests 的 最 大 比例 上 限 ， 此 外 
LimitRange 还 可 以 为 Pod 中 的 容器 提供 默认 的 资源 配置 。 


Kubernetes 基 于 Pod 的 资源 配置 (Requests 和 Limits) 实现 了 资源 服 
务 质量 (QoS) 。 不 同 QoS 级 别 的 Pod 在 系统 中 拥有 不 同 的 优先 级 : 高 
优先 级 的 Pod 具 有 更 高 的 可 靠 性 ， 可 以 用 于 运行 可 靠 性 要 求 较 高 的 服 


; 而 低 优先 级 的 Pod 可 以 实现 集群 资源 的 超 售 ， 能 有 效 地 提高 集群 
资源 利用 率 。 


人 eee A Un Er E A 
系 。 这 个 资源 管理 体系 已 经 可 以 满足 大 部 分 资源 管理 的 需求 了 。 同 
时 ，Kubernetes 资 源 管理 体系 仍然 在 不 停 地 发 展 和 进化 中 ， 对 于 一 些 
目前 无 法 满足 的 更 复杂 、 更 个 性 化 的 需求 ， 我 们 可 以 继续 关注 
Kubernetes 未 来 的 发 展 和 变化 。 


5.1.5 Kubemetes#2#¢ ra n] Aube 


Kubermnetes 作 为 容器 应 用 的 管理 平台 ， 通 过 对 Pod 的 运行 状况 进行 
监控 ， 并 且 根 据 主机 或 容 絮 失效 的 状态 将 新 的 Pod 调 度 到 其 他 Node 
上 ， 实 现 了 应 用 层 的 高 可 用 性 。 针 对 Kubemetes 人 集群， 高 可 用 性 还 应 
包含 以 下 两 个 层面 的 考虑 : etcd 数 据 存 储 的 高 可 用 性 和 Kubernetes 
Master 组 件 的 高 可 用 性 。 


1.etcd 高 可 用 部 署 


etcd 在 整个 Kubemetes 和 集群 中 处 于 中 心 数 据 库 的 地 位 ， 为 保证 
Kubernetes 集 群 的 高 可 用 性 ， 首 先 需要 保证 数据 库 不 是 单 故 障 点 。 一 
方面 ，etcd 需 要 以 集群 的 方式 进行 部 车， 以 实现 etcd 数 据 存 储 的 元 余 、 
备份 与 高 可 用 性 ; 另 一 方面 ，etcd 存 储 的 数据 本 身 也 应 考虑 使 用 可 靠 
的 存储 设备 。 


etcd 集 群 的 部 署 可 以 使 用 静态 配置 ， 也 可 以 通过 etcd 提 供 的 REST 
API 在 运行 时 动态 添加 、 修 改 或 删除 集群 中 的 成 员 。 本 市 将 对 etcd 集 群 
的 静态 配置 进行 说 明 。 关 于 动态 修改 的 操作 方法 请 参考 etcd 官 方 文档 
的 说 明 。 


首先 ， 规 划一 个 至 少 3 台 服务 器 (TA) 的 etcd 集 群 ， 在 每 台 服 务 
右上 安装 好 etcd。 


部 署 一 个 由 3 台 服 务 器 组 成 的 etcd 集 群 ， 其 配置 如 表 5.5 所 示 ， 其 集 
群 部 署 实 例如 图 5.5 所 示 。 


图 5.5 ”etcd 集 群 部 署 实 例 


表 5.5 ”etcd 集 群 的 配置 


etcd 实例 名 称 


etcdl 10.0.0.1 


10002 


10.0.0.3 


然后 修改 每 台 服 务 器 上 etcd 的 配置 文件 /etc/etcd/etcd.conf ° 


以 etdi 为 创建 集群 的 实例 ， 需 要 将 其 
ETCD INITIAL CLUSTER_STATE 设 置 为 “new”。etcd1 的 完整 配置 如 
ET 


# [member] 


ETCD NAME-etcd1 #etcd 实 例 名 称 


ETCD DATA DIR-"/var/lib/etcd" ”#etcd 数 据 保 存 目 录 


ETCD_LISTEN_CLIENT_URLS="http://10.0.0.1:2379,http://127.0. 


0.1:2379"  # 供 外 部 客户 端 使 用 的 URL 


ETCD ADVERTISE CLIENT URLS-"http://10.0.0.1:2379,http://127 
.0.0.1:2379" ”# 广 播 给 外 部 客户 端 使 用 的 URL 


#[cluster ] 


ETCD LISTEN PEER URLS-"http://10.0.0.1:2380" ”# 集 群 内 部 
通信 使 用 的 URL 


ETCD INITIAL ADVERTISE PEER URLS-"http://10.0.0.1:2380"  # 
广播 给 集群 内 其 他 成 员 访问 的 URL 


ETCD INITIAL CLUSTER-"etcdi-http://10.0.0.1:2380, etcd2=http 


://10.0.0.2:2380, etcd3-http://10.0.0.3:2380" # 初 始 集群 成 
员 列 表 

ETCD_INITIAL_CLUSTER_STATE="new" # 初 始 集群 状态 ，new 为 
新 建 集群 


ETCD INITIAL CLUSTER TOKEN-"etcd-cluster" # 集 群 名 称 


局 动 etcd1l 服 务 絮 上 的 etcd 服 务 : 


$ systemctl restart etcd 


EIZ, WAE T —^ 45 Netcd-clustert 48 f£ ° 


etcd2 和 etcd3 为 加 A etcd-cluster 集群 的 实例 ， 需 要 将 其 
ETCD INITIAL CLUSTER_STATE 设 置 为 “exist”。etcd2 的 完整 配置 如 
下 (etcd3 的 配置 略 ) : 


# [member ] 


ETCD NAME=etcd2 #etcd 实 例 名 称 


ETCD_DATA_DIR="/var/lib/etcd" ”#etcd 数 据 保 存 目 录 


ETCD LISTEN CLIENT URLS-"http://10.0.0.2:2379,http://127.0. 
0.1:2379" ”# 供 外 部 客户 端 使 用 的 URL 


ETCD ADVERTISE CLIENT URLS-"http://10.0.0.2:2379,http://127 
.0.0.1:2379" ”# 广 播 给 外 部 客户 端 使 用 的 URL 
#[cluster ] 


ETCD LISTEN PEER URLS-"http://10.0.0.2:2380" ”# 集 群 内 部 
通信 使 用 的 URL 


ETCD INITIAL ADVERTISE PEER URLS-"http://10.0.0.2:2380"  # 
广播 给 集群 内 其 他 成 员 使 用 的 URL 


ETCD_INITIAL_CLUSTER="etcd1=http://10.0.0.1:2380, etcd2=http 


://10.0.0.2:2380, etcd3=http://10.0.0.3:2380" # 初 始 集群 成 


ETCD_INITIAL_CLUSTER_STATE="new" # 初 始 集群 状态 ，new 


为 新 建 集 群 
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" # 集 群 名 称 


局 动 etcd2 和 etcd3 服 务 器 上 的 etcd 服 务 : 


$ systemctl restart etcd 


Am, ete meted D 441A 1etcdctl cluster-health fig 3K & 18] 
集群 的 运行 状态 : 


C 


$ etcdctl cluster-health 

cluster is healthy 

member ce2a822cea30bfca is healthy 
member acda82baicf790fc is healthy 
member eba209cd0012cd2 is healthy 


在 任意 etcd 节 点 上 执行 etcdctl member list 命 令 来 查询 集群 的 成 员 列 
XE. 


$ etcdctl member list 
ce2a822cea30bfca: name=default 
peerURLs=http://10.0.0.1:2380,http://127.0.0.1:7001 


clientURLs-http://10.0.0.1:2379,http://127.0.0.1:2379 
acda82baidcf790fc: name-default 


peerURLs=http://10.0.0.2:2380,http://127.0.0.1:7001 
clientURLs-http://10.0.0.2:2379,http://127.0.0.1:2379 
eba209cd40012cd2: name-default 
peerURLs-http://10.0.0.3:2380,http://127.0.0.1:7001 
clientURLs-http://10.0.0.3:2379,http://127.0.0.1:2379 


至 此 ， 一 个 etcd 集 群 束 创建 成 功 了 。 
以 kube-apiserver 为 例 ， 将 访问 etcd 集 群 的 参数 设置 为 : 


--etcd- 
servers=http://10.0.0.1:2379,http://10.0.0.2:2379,http://10 
.0.0.3:2379 


在 etcd 集 群 成 功 司 动 之 后 ， 如 果 需 要 对 集群 成 员 进 行 修改 ， 则 请 
参考 官方 文档 的 详细 说 明 : 


https://github.com/coreos/etcd/blob/master/Documentation/ru 


ntime-configuration.md#cluster-reconfiguration-operations ° 
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列 、 高 性 能 存储 设备 、 共 序 存 储 文件 系统 ， 或 者 使 用 云 服 务 商 提供 的 
存储 系统 等 来 实现 。 


2. Master ij Hn] HX 


在 Kubernetes 系 统 中 ，Master 服 务 扮演 着 总 探 中 心 的 角色 ， 主 要 的 
三 个 服务 kube-apiserver、kube-controller-mansger 和 kube-scheduler 通 过 
不 断 与 工作 节点 上 的 kubelet 和 kube-proxy 进 行 通 信 来 维护 整个 集群 的 
健康 工作 状态 。 如 果 Master 的 服务 无 法 访问 到 某 个 Node， 则 会 将 该 
Node 标 记 为 不 可 用 ， 不 再 回 其 调度 新 建 的 Pod。 但 对 Master 目 吴 则 需要 
进行 额外 的 监控 ， 使 Master 不 成 为 集群 的 单 故障 点 ， 所 以 对 Master 服 
务 也 需要 进行 高 可 用 方式 的 部 署 。 


以 Master 的 kube-apiserver ^ kube-controller-mansger 和 kube- 
scheduler 三 个 服务 作为 一 个 部 署 单元 ， 类 似 于 etcd 集 群 的 典型 部 署 配 
置 。 使 用 至 少 三 台 服 务 絮 安装 Master 服 务 ， 并 且 需 要 保证 任何 时 候 总 
有 一 套 Master 能 够 正常 工作 。 图 5.6 展 示 了 一 种 典型 的 部 署 方式 。 


Master 1 Master 2 
kube-controller- kube-controller- kube-controller- 
manster manster manster 


kube-apiserver kube -apiserver kube-apiserver 


Master 3 


负载 均衡 器 
(Master 访 问 入 口 ) 


ET 
Node 
[Node 


5.6 ”KubermetesMaster 高 可 用 部 署 架 构 


Kubernetes X MasterfJ3 A HIFA ARRERA, Ae) 
的 基础 ale kubelet ， 所 以 它们 都 将 以 Static Pod 的 形式 启动 并 由 
kubelet 进 行 监控 和 目 动 重 局。 而 kubelet 本 刁 的 高 可 用 则 通过 探 作 系 统 
来 完成 ， " 如 使 用 Linux 的 Systemd 系 统 进行 管理 。 


E e 井 程 ， 则 需要 先 停止 它们 ， 然 后 启 
es. 这 3 个 主 进程 将 通过 kubelet 以 容器 的 形式 启动 和 运行 


o 


接 下 来 分 别 对 kube-apiserver 和 kube-controller-manager ^ kube- 
scheduler 的 高 可 用 部 署 进行 说 明 。 


1) kube-apiserver 的 高 可 用 部 署 


根据 第 2 章 的 介绍 ， 为 kube-apiserver 预 先 创 建 所 有 需要 的 CA 证 书 
TEREUS, RISES BARB as EOE H ICE: 


# touch /var/1log/kube-apiserver.log 


{Fc i kubelet HY JB 2/] 3 18 FE --config-/etc/kubernetes/manifests, ， 即 
Static Pod 定 义 文件 所 在 的 目录 ， 接 下 来 就 可 以 创建 kube-apiserver.yaml 
配置 文件 用 于 局 动 kube-apiserver J ° 


kube-apiserver.yaml 
apiVersion: vi 
kind: Pod 
metadata: 
name: kube-apiserver 


spec: 


hostNetwork: true 
containers: 
- name: kube-apiserver 
image: gcr.io/google containers/kube- 
apiserver:9680e782e08a1a1c94c656190011bd02 
command: 
- /bin/sh 
- -C 
- /usr/local/bin/kube-apiserver  --etcd- 
servers=http://127.0.0.1:2379 
- admission- 
control=NamespaceLifecycle, LimitRanger,SecurityContextDeny, 
ServiceAccount, ResourceQuota 
--service-cluster-ip-range=169.169.0.0/16 --v-2 
--allow-privileged=False 1>>/var/log/kube- 
apiserver.log 2>&1 
ports: 
- containerPort: 443 
hostPort: 443 
name: https 
- containerPort: 7080 
hostPort: 7080 
name: http 
- containerPort: 8080 
hostPort: 8080 
name: local 


volumeMounts: 


mountPath: /srv/kubernetes 
name: srvkube 

readOnly: true 

mountPath: /var/log/kube-apiserver.log 
name: logfile 

mountPath: /etc/ssl 

name: etcssl 

readOnly: true 

mountPath: /usr/share/ssl 
name: usrsharessl 
readOnly: true 

mountPath: /var/ssl 

name: varssl 

readOnly: true 

mountPath: /usr/ssl 

name: usrssl 

readOnly: true 

mountPath: /usr/lib/ssl 
name: usrlibssl 

readOnly: true 

mountPath: /usr/local/openssl 
name: usrlocalopenssl 
readOnly: true 

mountPath: /etc/openssl 
name: etcopenssl 

readOnly: true 


mountPath: /etc/pki/tls 


name: etcpkitls 
readOnly: true 
volumes: 
- hostPath: 
path: /srv/kubernetes 
name: srvkube 
- hostPath: 
path: /var/log/kube-apiserver.log 
name: logfile 
- hostPath: 
path: /etc/ssl 
name: etcssl 
- hostPath: 
path: /usr/share/ssl 
name: usrsharessl 
- hostPath: 
path: /var/ssl 
name: varssl 
- hostPath: 
path: /usr/ssl 
name: usrssl 
- hostPath: 
path: /usr/lib/ssl 
name: usrlibssl 
- hostPath: 
path: /usr/local/openssl 


name: usrlocalopenssl 


- hostPath: 
path: /etc/openssl 
name: etcopenssl 
- hostPath: 
path: /etc/pki/tls 


name: etcpkitls 


其 中 ， 


e kube-apiserver 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 宿主 机 网 
络 ， 以 使 得 客户 端 能 够 通过 物理 机 访问 其 API。 
镜像 的 tag 来 源 于 kubernetes 发 布 包 中 的 kube-apiserverdocker tag 


件 : kubernetes/server/kubernetes-server-linux- 


amd64/server/bin/kube-apiserver.docker_tag ° 
e --etcd-servers: 指定 etcd 服 务 的 URL 地 址 。 
再 加 上 其 他 必要 的 启动 参数 ， 包 括 --admission-control 、--service- 
cluster-ip-range、CA 证 书 相 关 配 置 等 内 容 。 
端口 号 的 设置 都 配置 了 hostPort， 将 容 吉 内 的 端口 号 直接 映射 为 宿 
主机 的 端口 号 。 


Tf kube-apiserveryaml XC fF 复 制 到 kubelet Ji 控 
的 /etc/kubernetes/manifests 日 好 下 ，kubelet 将 会 自动 创建 yaml 文 件 中 定 
义 的 kube-apiserver 的 Pod ° 


接 下 来 在 另外 两 台 服 务 器 上 重复 该 操作 ， 使 得 每 台 服 务 右 上 都 局 
动 一 个 kube-apiserver 的 Pod 。 


2) 为 kube-apiserver 配 置 负载 均衡 需 


至 此 ， 我 们 启动 了 三 个 kube-apiserver 实 例 ， 这 三 个 kube-apiserver 
都 可 以 正常 工作 ， 我 们 需要 一 个 统一 的 、 可 靠 的 、 人 允许 部 分 Master 琅 
点 故障 的 方式 来 访问 它们 ， 可 以 通过 部 署 一 个 负载 均衡 喜来 实现 。 


在 不 同 的 平台 下 ， 负 载 均衡 的 实现 方式 不 同 : 在 一 些 公用 云 比如 
GCE、AWS、 阿 里 云 上 都 有 现成 的 实现 方案 ， 对 于 本 地 集群 ， 我 们 可 
以 选择 硬件 或 者 软件 来 实现 负载 均衡 ， 比 如 Kubernetes 社 区 推荐 的 方 
案 haproxy 和 keepalived 来 实现 ， 其 中 haproxy 做 负载 均衡 ， 而 keepalived 
人 负责 对 haproxy 监 控 和 进行 高 可 用 。 


在 完成 API Server 的 负载 均衡 配置 之 后 ， 对 其 访问 还 需要 注意 以 下 
内 容 。 


m 


。 如 条 Master 开 局 了 安全 认证 机 制 ， 那 么 需要 确保 证 书 中 包含 负载 
均衡 服务 万 点 的 IP © 

。 对 于 外 部 的 访问 ， 比 如 通过 kubectl 访 问 API Server, JA RRMA 
为 访问 API Server 对 应 的 负载 均衡 侨 的 IP 地 址 。 


3) kube-controller-manager 和 kube-scheduler 的 高 可 用 配置 


不 同 于 API Server, ，Master 中 另外 两 个 核心 组 件 kube-controller- 
manager 和 kube-scheduler 会 修改 集群 的 状态 信息 ， 因 此 对 于 kube- 
controller-manager 和 kube-scheduler 而 言 ， 高 可 用 不 仪 意味 着 需要 启动 
多 个 实例 ， 还 需要 这 多 个 实例 能 实现 选举 并 选举 出 leader， 以 保证 同一 
时 间 只 有 一 个 实例 可 以 对 集群 状态 信息 进行 读 写 ， 避 免 出 现 同步 问题 
和 一 致 性 问题 。Kubernetes 对 于 这 种 选举 机 制 的 实现 是 采用 租赁 锁 

(lease-lock) 来 实现 的 ， 我 们 可 以 通过 在 kube-controller-manager 和 


kube-scheduler 的 每 个 实例 的 启动 参数 中 设置 --leader-elect=true， 来 保证 
同一 时 间 只 会 运行 一 个 可 修改 集群 信息 的 实例 。 


Scheduler 和 Controller Manager 高 可 用 的 具体 实现 方式 如 下 。 


ESC TE BET Master P 点 上 创建 相应 的 日 志文 件 : 


# touch /var/log/kube-scheduler.log 


# touch /var/log/kube-controller-manager.log 


9X Ia fil] $& kube-controller-manager #4 kube-scheduler HH‘) Pod E X X 
f: 


kube-controller-manager.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 
name: kube-controller-manager 
spec: 
hostNetwork: true 
containers: 
- name: kube-controller-manager 
image: gcr.io/google containers/kube-controller- 
manager:fda24638d51a48baa13c35337fcd4793 
command: 
- /bin/sh 
- -C 


- /usr/local/bin/kube-controller-manager -- 


master-127.0.0.1:8080 
--v=2 --leader-elect=true 1>>/var/log/kube- 
controller-manager.log 2>&1 
livenessProbe: 
httpGet: 
path: /healthz 
port: 10252 
initialDelaySeconds: 15 
timeoutSeconds: 1 
volumeMounts: 
- mountPath: /srv/kubernetes 
name: srvkube 
readOnly: true 
- mountPath: /var/log/kube-controller-manager.log 
name: logfile 
- mountPath: /etc/ssl 
name: etcssl 
readOnly: true 
- mountPath: /usr/share/ssl 
name: usrsharessl 
readOnly: true 
- mountPath: /var/ssl 
name: varssl 
readOnly: true 
- mountPath: /usr/ssl 
name: usrssl 


readOnly: true 


- mountPath: /usr/lib/ssl 
name: usrlibssl 
readOnly: true 

- mountPath: /usr/local/openssl 
name: usrlocalopenssl 
readOnly: true 

- mountPath: /etc/openssl 
name: etcopenssl 
readOnly: true 

- mountPath: /etc/pki/tls 
name: etcpkitls 
readOnly: true 

volumes: 
- hostPath: 
path: /srv/kubernetes 
name: srvkube 
- hostPath: 
path: /var/log/kube-controller-manager.log 
name: logfile 
- hostPath: 
path: /etc/ssl 
name: etcssl 
- hostPath: 
path: /usr/share/ssl 
name: usrsharessl 
- hostPath: 


path: /var/ssl 


name: varssl 
- hostPath: 
path: /usr/ssl 
name: usrssl 
- hostPath: 
path: /usr/lib/ssl 
name: usrlibssl 
- hostPath: 
path: /usr/local/openssl 
name: usrlocalopenssl 
- hostPath: 
path: /etc/openssl 
name: etcopenssl 
- hostPath: 
path: /etc/pki/tls 


name: etcpkitls 


其 中 ， 


kube-controller-manager 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 衔 
主机 网 络 。 

T UR BJ tag 来源 于 kuberetes 发 布 包 中 的 kube-controller- 
manager.docker tag 文件 : kubernetes/server/kubernetes-server-linux- 
amd64/server/bin/kube-controller-manager.docker tag ° 
--master: 指定 kube-apiserver 服 务 的 URL 地 址 。 

--leader-elect=true: 使 用 leader 选 举 机 制 。 


kube-scheduler.yaml: 
apiVersion: v1 
kind: Pod 
metadata: 
name: kube-scheduler 
spec: 
hostNetwork: true 
containers: 
- name: kube-scheduler 
image: gcr.io/google containers/kube- 


scheduler:34d0b8f8b31e27937327961528739bc9 


command: 
- /bin/sh 
- -C 
-  /usr/local/bin/kube-scheduler -- 
master-127.0.0.1:8080 --V-2 --leader-elect=true 


1>>/var/log/kube-scheduler.log 2>&1 
livenessProbe: 
httpGet: 
path: /healthz 
port: 10251 
initialDelaySeconds: 15 
timeoutSeconds: 1 
volumeMounts: 
- mountPath: /var/log/kube-scheduler .log 


name: logfile 


- mountPath: 
/var/run/secrets/kubernetes.io/serviceaccount 
name: default-token-s8ejd 
readOnly: true 
volumes: 
- hostPath: 
path: /var/log/kube-scheduler.log 


name: logfile 


其 中 ， 


e kube-scheduler 需 要 使 用 hostNetwork 模 式 ， 即 直接 使 用 宿主 机 网 


络 。 
。 镜像 的 tag 来 源 于 kubernetes 发 布 包 中 的 kube-schedulerdocker tag X 
件 : kubernetes/server/kubernetes-server-linux- 


amd64/server/bin/kube-scheduler.docker_tag ° 
--master: 指定 kube-apiserver 服 务 的 URL 地 址 。 
--leader-elect=true: 使 用 leader 选 举 机 制 。 


将 这 两 个 yaml 文 件 复制 到 kubelet 监 控 的 /etc/kubernetes/manifests 日 
录 下 ，kubelet 将 会 目 动 创建 yaml 文 件 中 定义 的 kube-controller-manager 
和 kube-scheduler 的 Pod ° 


至 此 ， 我 们 完成 了 Kubernetes Master 组 件 高 可 用 的 完整 配置 ， 配 

a 整个 Kubernetes 集 群 的 高 可 用 已 经 全 部 完成 。 最 

， 只 需要 确认 集群 中 所 有 访问 API Server 的 地 方 都 已 经 将 访问 地 址 修 
ae 载 均 衡 的 地 址 ， 残 可 以 保证 集群 高 可 用 的 正常 工作 了 。 


3.Master 高 可 用 架构 的 演进 


在 当前 的 版 本 中 ，kubelet 可 以 设置 “--api-servers” 启 动 参数 来 指定 
多 个 kube-apiserver， 但 是 当 第 1 个 kube-apiserver 不 可 用 之 后 ，kubelet 无 
法 连接 到 后 面 的 kube-apiserver， 也 融 是 说 只 有 第 1 个 kube-apiserver 起 作 
用 。 如 果 这 个 问题 得 到 解决 ， 则 kubelet 无 须 通 过 额外 的 负载 均衡 器 就 
能 连接 到 多 个 API Server 了 。 


另外， 除了 kubelet， 其 他 核心 组 件 kube-controller-manager ` kube- 
scheduler fil kube-proxy 4b fig 22 fc & kube-apiserver, H REIN AWE 
数 “--master” 仪 支持 配置 一 个 kube-apiserver ， 还 无 法 支持 多 个 kube- 
apiserver 的 配置 。 


Kubernetes 计 划 在 后 续 的 版 本 中 文 持 多 个 Master 的 配置 ， 实 现 不 需 
要 负载 均衡 器 的 Master 高 可 用 架构 » 
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1. 通 过 cAdvisor 页 面 查看 容器 的 运行 状态 


开源 软件 cAdvisor (Container Advisor) 是 用 于 监控 容器 运行 状态 
的 利 sz 之 一 ( cAdvisor 项 H Bj Xx 页 为 
https://github.com/google/cadvisor) ， 它 被 用 于 多 个 与 Docker 相 关 的 开 
产 项 目 中 。 


在 Kubernetes 系 统 中 ，cAdvisor 已 被 默认 集成 到 了 kubelet 组 件 内 ， 
当 kubelet 服 务 启动 时 ， 它 会 目 动 启动 cAdvisor 服 务 ， 然 后 cAdvisor 会 实 
时 采集 所 在 市 点 的 性 能 指标 及 在 节点 上 运行 的 容器 的 性 能 指标 。 
kubelet 的 启动 参数 --cadvisor-port 可 目 定义 cAdvisor 对 外 提供 服务 的 端 
口号 ， 默 认为 4194。 


cAdvisor 提 供 了 Web 页 面 可 供 浏 览 絮 访问 。 例 如 Kubernetes 集 群 中 
的 一 个 Node 的 IP 地 址 是 192.168.18.3， 则 在 浏览 器 中 输入 网 址 
http://192.168.18.3: 4194 来 访问 cAdvisor 的 监控 页 面 。cAdvisor 的 主页 
显示 了 主机 的 实时 运行 状态 ， 包 括 CPU 使 用 情况 、 内 存 使 用 情况 、 网 
络 吞 吐 量 及 文件 系统 使 用 情况 等 信息 。 


图 5.7 展 示 了 cAdvisor 的 几 个 性 能 监控 页 面 。 
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图 5.7 主机 的 性 能 监控 页 面 


通过 Docker Containers 链 接 可 以 查看 容器 列表 及 每 个 容 絮 的 性 能 数 
据 ， 如 图 5.8 所 示 。 


: EEs| (es crea 
ERAN, E Rai F ED 


Subcontainers 


5.8. Ata APE RE a fat ULTRI 


此 外 ，cAdvisor 也 提供 了 REST API 供 客户 端 远程 调用 ， 主 要 是 为 
了 定制 开发 ，API 返 回 的 数据 格式 为 JSJON， 可 以 采用 如 下 URL 来 访 


fa]: 


http://<hostname>:<port>/api/<version>/<request> 


例如 ， 通 过 URL http://192.168.18.3: 4194/api/v1.3/machine Fy LI ŽK 
取 主 机 的 相关 信息 : 


"num_cores":2, 
"cpu_frequency_khz":2793544, 
"memory _capacity":1915408384, 
"machine_id":"0f6233d8256a4ec1a673640e04b8344a", 
"system uuid":"564D188F-8E82-21C0-6E89- 
176E2C51EBB5", 
"boot_id":"a03d00d8 -ca9c-4d74-a674-ebf5dfbc69d9", 


"filesystems": [ 


{ 
"device":"/dev/mapper/rhel-root", 
"Capacity":18746441728 
3 
{ 
"device":"/dev/sda1'", 
"capacity":520794112 
} 
]; 
"disk map":( 


"253:0":{ 


"name" :"dm-0", 
"major" :253, 
"minor":0, 

"size" :2147483648, 


"scheduler":"none" 


ty 
ty 
"network_devices": [ 
{ 
"name" :"eno16777736", 
"mac_address":"00:0c:29:51:eb:b5", 
"speed":1000, 
"mtu":1500 
} 
], 
"topology": [ 
{ 


"node_id":0, 

"memory" :2146947072, 

"cores": [ 

{ 
"core_id":0, 
"thread ids":[ 
0 

], 


"caches":null 


]; 


"caches":[ 


{ 
"size":6291456, 


"type":"Unified", 
"level":3 


通过 下 面 的 URL 则 可 以 获取 节点 上 最 新 (1 分 钟 内 ) 的 容器 的 性 能 
数 据 : http://192.168.1.129 
4194/api/v1.3/subcontainers/system.slice/docker- 
5015d5c7ef72b98627332fabd031251cbd3f191418500f7aec6b9950399661e 


d.scope ° 


结果 为 : 


"name":"/system.slice/docker - 
5015d5c7ef72b98627332fabd031251cbd3f191418500f 7aec6b9950399 


661ed.scope", 


"aliases": [ 
"k8s master. f8a6f6df_Redis-master- 
6o0kig_default_9c428d4f -4167-11e5-afe7- 


000c2921ba71_5dce2f85", 


"59015d5c7ef72b98627332fabd031251cbd3f191418500f 7aec6b995039 
9661ed" 
], 
"namespace":"docker", 
"spec": { 
"creation time":"2015-08- 
17T08:44:27.401122502Z", 


"labels":( 


"io.kubernetes.pod.name":"default/Redis-master-6okig" 
ty 

"has_cpu": true, 

"cpu" :( 

"limit":2, 
"max limit":0, 
"mask" :"9-1" 

ty 

"has_memory":true, 

"memory": { 
"limit":18446744073709552000, 
"swap limit":18446744073709552000 

ty 


"has_network": true, 
"has_filesystem": false, 
"has_diskio": true 
ty 
"stats": [ 
{ 
"timestamp":"2015-08- 
18T00 :54:26.167988505+08:00", 
"cpu": { 
"usage": { 
"total" :43121463207, 
"per cpu usage":[ 
21578091763, 
21543371444 
], 
"user" :410000000, 


"system" :13620000000 


ty 
"load_average":0 
ty 
"diskio":{ 


"io service bytes":[ 


{ 
"major":253, "minor":14, 


"stats": { 


"Async" : 8036352, "Read": 8036352, "Sync":0, "Total": 8036352, "Wr 


ite":0 


], 
"io serviced": [ 
{ 
"major":8, 
"minor":0, 
"stats":( 
"Async":0, 


3 
"memory": { 
"usage":16748544, 
"working set":9297920, 
"container data":( 
"pgfault":882, 
"pgmajfault":8 
ty 
"hierarchical data":( 
"pgfault":882, 


"pgmajfault":8 


ty 
"network" :( 


"hame" : we " 


"rx_bytes":0,"rx_packets":0,"rx_errors":0,"rx_dropped":0,"t 
x bytes":0,"tx packets":0,"tx errors":0,"tx dropped":0 

ty 

"task stats":( 


"nr sleeping":0,"nr running":0,"nr stopped":0,"nr uninterru 
ptible":0,"nr io wait":0 
} 
3 


容器 的 性 能 数据 对 于 集群 监控 非常 有 用 ， 系 统管 理 员 可 以 根据 
cAdvisor 提 供 的 数据 进行 分 析 和 告警 。 不 过 ， 由 于 cAdvisor 是 在 每 全 
Node 上 运行 的 ， 只 能 采集 本 机 的 性 能 指标 数据 ， 所 以 系统 管理 员 需 要 
对 每 台 Node 主 机 单独 监控 。 


针对 大 型 集群 ，Kubernetes 建 议 使 用 几 个 开源 软件 组 成 的 集成 解 
决 方案 来 实现 对 整个 集群 的 监控 。 这 些 开 源 软 件 包 括 Heapster、 
InfluxDB 及 Grafana 等 。 


2.Heapster+Influxdb+Grafana 集 群 性 能 监控 平台 搭建 


ia 
E 


根据 前 面 的 说 明 ，cAdvisor 集 成 在 kubelet 中 ， 运 行 在 每 个 Node 
所 以 一 个 cAdvisor 仅 能 对 一 台 Node 进 行 监 探 。 在 大 规模 容器 集群 
需要 对 所 有 Node 和 全 部 容器 进行 性 能 监控 ，Kubernetes 建 议 使 用 


一 套 工 具 来 实现 集群 性 能 数据 的 采集 、 存 储 和 展示 : Heapster、 


InfluxDBZllGrafana ° 


Heapster: 对 集群 中 各 Node 上 cAdvisor 的 数据 采集 汇聚 的 系统 ， 通 
过 访问 每 个 Node 上 kubelet 的 API， 再 通过 kubelet 调 用 cAdvisor 的 
API 来 采集 该 节点 上 所 有 容 如 的 性 能 数据 。Heapster 对 性 能 数据 进 
行 聚 合 ， 并 将 结果 保存 到 后 端 存 储 系统 中 。Heaspter 文 持 多 种 后 
端 存 储 系 统 ， 包 括 memory (保存 在 内 存 中 ) ^ InfluxDB ` 
BigQuery ^ £ Wk Z ^F A $e f AY Google Cloud Monitoring 
( https://cloud.google.com/monitoring/ ) 和 Google Cloud Logging 
( https://cloud.google.com/logging/) 等 。Heapster 项 目的 主页 为 
https://github.com/kubernetes/heapster ° 
InfluxDB: 是 分 布 式 时 序数 据 库 〈 每 条 记录 都 带 有 时 间 戳 属 
PE) ， 主 要 用 于 实时 数据 采集 、 事 件 跟踪 记录 、 存 储 时 间 图 表 、 
原始 数据 等 。InfluxDB 提 供 T REST API 用 于 数据 的 存储 和 查询 。 
InfluxDB 的 主页 为 http://influxdb.com ° 
Grafana: 通过 Dashboard 将 InfluxDB 中 的 时 序数 据 展现 成 图 表 或 曲 
线 等 形式 ， 便 于 运 维和 人 员 查 看 集群 的 运行 状态 。Grafana 的 主页 为 
http://grafana.org ° 


基于 heapster+influxdb+grafana 的 集群 监控 系统 总 体 架 构 如 图 5.9 所 
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图 5.9 ”Heapster 集 群 监控 系 


| 


influxdb 


kubelet 


Node 


统 以 构 


Heapster、InfluxDB 和 Grafana 均 以 Pod 的 形式 启动 和 运行 。 由 于 
Heapster 需 要 与 Kubernetes Master 进 行 安全 连接 ， 所 以 需要 设置 Master 
的 CA 证 书 安全 策略 〈 参 见 第 2 章 的 说 明 ) 


o 


1) Hb Heapster ` InfluxDB ^ Grafana¥4s V FA 


先 创 建 它 们 的 Service: 


heapster-service.yaml 


apiVersion: v1 
kind: Service 
metadata: 


labels: 


kubernetes.io/cluster-service: "true" 


kubernetes.io/name: Heapster 


name: heapster 


namespace: kube-system 


spec: 
ports: 
- port: 80 
targetPort: 8082 
selector: 


k8s-app: heapster 


influxdb-service.yaml 


apiVersion: vi 
kind: Service 
metadata: 
labels: null 
name: monitoring-InfluxDB 
namespace: kube-system 
spec: 


type: NodePort 


ports: 
- name: http 
port: 8083 


targetPort: 8083 
nodePort: 8083 

- name: api 
port: 8086 


targetPort: 8086 


nodePort: 8086 
selector: 


name: influxGrafana 


NUS 这 里 使 用 type=NodePort 将 InfluxDB 暴 露 在 宿主 机 Node 的 端 


以 便 我 们 使 用 浏览 器 对 其 进行 访问 。 


grafana-service.yaml 


apiVersion: vi 
kind: Service 
metadata: 
labels: 
kubernetes.io/name: monitoring-Grafana 
kubernetes.io/cluster-service: "true" 
name: monitoring-Grafana 
namespace: kube-system 
spec: 
type: NodePort 
ports: 
- port: 80 
targetPort: 8080 
nodePort: 8085 
selector: 


name: influxGrafana 


同样 ， 使 用 type=NodePort 将 Grafana 暴 露 在 Node 的 端口 上 ， 以 便 客 
户 端 的 浏览 器 对 其 进行 访问 。 


使 用 kubectl create 命 令 创 建 Services: 


$ kubectl create -f heapster-service.yaml 
$ kubectl create -f InfluxDB-service.yaml 


$ kubectl create -f Grafana-service.yaml 


在 创建 heapster 容 器 之 前 ， 先 创建 InfluxDB 和 Grafana 的 RC， 这 两 
个 容器 将 运行 在 同一 个 Pod 中 : 


influxdb-grafana-controller-v3.yaml 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: monitoring-influxdb-grafana-v3 
namespace: kube-system 
labels: 
k8s-app: influxGrafana 
version: v3 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: influxGrafana 


version: v3 


template: 
metadata: 
labels: 
k8s-app: influxGrafana 
version: v3 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- image: 
gcr.io/google containers/heapster influxdb:v0.5 
name: influxdb 
resources: 
# keep request = limit to keep this 
container in guaranteed class 
limits: 
cpu: 100m 
memory: 500Mi 
requests: 
cpu: 100m 
memory: 500Mi 
ports: 
- containerPort: 8083 
- containerPort: 8086 
volumeMounts: 
- name: influxdb-persistent-storage 
mountPath: /data 


- image: 


gcr.io/google containers/heapster grafana:v2.6.0-2 
name: grafana 
resources: 
limits: 
cpu: 100m 
memory: 100Mi 
requests: 
cpu: 100m 
memory: 100Mi 
env: 
# This variable is required to setup 
templates in Grafana. 
- name: INFLUXDB SERVICE URL 
value: http://monitoring-influxdb:8086 
# The following env variables are 
required to make Grafana accessible via 
# the kubernetes api-server proxy. On 
production clusters, we recommend 
# removing these env variables, setup 
auth for grafana, and expose the grafana 
# service using a LoadBalancer or a 
public IP. 
- name: GF AUTH BASIC ENABLED 
value: "false" 
- name: GF AUTH ANONYMOUS ENABLED 
value: "true" 


- name: GF AUTH ANONYMOUS ORG ROLE 


value: Admin 
- name: GF_SERVER_ROOT_URL 
value: /api/vi/proxy/namespaces/kube- 
system/services/monitoring-grafana/ 
volumeMounts: 
- name: grafana-persistent-storage 
mountPath: /var 
volumes: 
- name: influxdb-persistent-storage 
emptyDir: {} 
- name: grafana-persistent-storage 


emptyDir: {} 


注意 ，Grafana 容 器 环境 变量 INFLUXDB_SERVICE_URL 设 置 为 
InfluxDB 服 务 的 所 在 地 址 。 由 于 Grafana 与 InfluxDB 处 于 同一 个 Pod 中 ， 
所 以 Grafana 使 用 127.0.0.1 或 localhost 也 可 以 访问 到 InfluxDB 服 务 。 


使 用 kubectl create 命 令 创 建 该 RC: 


$ kubectl create -f influxdb-grafana-controller- 


v3.yaml 


通过 kubectl get pods--namespace-kube-systemfff YA Pod Aa: 


# kubectl get pods --namespace-kube-system 
NAME READY 
STATUS RESTARTS AGE 


monitoring-influxdb-grafana-v3-uu730 2/2 


Running 0 4m 


A f&heapsterZtz&, v1.1.0] Æ BJ heapster H 4^ £88 2H A 79 — A 
Pod: 


heapster-controller-v1.1.0.yaml 


apiVersion: extensions/vibeta1 
kind: Deployment 
metadata: 
name: heapster-v1.1.0 
namespace: kube-system 
labels: 
k8s-app: heapster 
kubernetes.io/cluster-service: "true" 
version: v1.1.0 
spec: 
replicas: 1 
selector: 
matchLabels: 
k8s-app: heapster 
version: v1.1.0 
template: 
metadata: 
labels: 


k8s-app: heapster 


version: vi.1.0 
spec: 


# 4 containers, 2 heapsters, 2 resizer 


containers: 
- image: 
gcr.io/google containers/heapster:v1.1.0 
name: heapster 
resources: 
# keep request = limit to keep this 


container in guaranteed class 
limits: 
cpu: 100m 
memory: 200Mi 
requests: 
cpu: 100m 
memory: 200Mi 
command : 


- /heapster 


source-kubernetes.summary api:'192.168.18.3:8080' 
- --sink-influxdb:http://monitoring- 
influxdb:8086 
- --metric resolution-60s 
- image: 
gcr.io/google containers/heapster:v1.1.0 
name: eventer 


resources: 


# keep request = limit to keep this 


container in guaranteed class 


inf luxdb: 8086 


resizer:1.3 


limits: 
cpu: 100m 
memory: 200Mi 
requests: 
cpu: 100m 
memory: 200Mi 
command : 
- /eventer 
- --source=kubernetes: '192.168.18.3:8080' 


- --sink-influxdb:http://monitoring- 


- image: gcr.io/google containers/addon- 


name: heapster-nanny 
resources: 
limits: 
cpu: 50m 
memory: 100Mi 
requests: 
cpu: 50m 
memory: 100Mi 
env: 
- name: MY POD NAME 
valueFrom: 


fieldRef: 


fieldPath: metadata.name 
- name: MY_POD_NAMESPACE 
valueFrom: 
fieldRef: 


fieldPath: metadata.namespace 


command: 
- /pod_nanny 
- --cpu-100m 


- --extra-cpu=0m 
- --memory-200Mi 
- --extra-memory-4Mi 
- --threshold-5 
- --deployment-heapster-v1.1.0 
- --container-heapster 
- --poll-period-300000 
- --estimator=exponential 
- image: gcr.io/google containers/addon- 
resizer:1.3 
name: eventer-nanny 
resources: 
limits: 
cpu: 50m 
memory: 100Mi 
requests: 
cpu: 50m 
memory: 100Mi 


env: 


- name: MY_POD_NAME 
valueFrom: 
fieldRef: 
fieldPath: metadata.name 
- name: MY POD NAMESPACE 
valueFrom: 
fieldRef: 


fieldPath: metadata.namespace 


command: 
- /pod_nanny 
- --cpu-100m 


- --extra-cpu=0m 

- --memory-200Mi 

- --extra-memory=500K1i 

- --threshold=5 

- --deployment-heapster-v1.1.0 
- --container=eventer 

- --poll-period=300000 


- --estimator=exponential 


Heapster 需 要 设置 的 启动 参数 如 下 。 
(1) -source 


配置 采集 来 源 ， 为 Master URL 地 址 : 


--source-kubernetes.summary api:'192.168.18.3:8080' 


(2) -sink 
配置 后 端 存 储 系统 ， 使 用 mfluxDB 系 统 : 


--Sink=InfluxDB:http://monitoring-InfluxDB: 8086 


(3) --metric_resolution 


性 能 指标 的 精度 ，60s 表 示 将 过 去 60 秒 的 数据 进行 汇聚 再 进行 存 
储 。 

其 他 参数 可 以 通过 进入 heapster 容 器 执行 如 eapster--help 命 令 查看 和 
设置 。 


注意 ，URL 中 的 主机 名 地 址 使 用 的 是 InfluxDB 的 Service 名 字 ， 这 
需要 DNS 服务 正常 工作 ， 如 果 没 有 配置 DNS 服务 ， 则 也 可 以 使 用 
Service 的 ClusterIP 地 址 。 


值得 说 明 的 是 ，InfluxDB 服 务 的 名 称 没有 加 上 命名 空间 ， 是 因为 
Heapster 服 务 与 mfluxDB 服 务 属 于 相同 的 命名 空间 kube-system。 当然 ， 
使 用 带 上 命名 空间 的 全 服务 名 也 是 可 以 的 ， 例 如 http:/monitoring- 
influxdb.kube-system: 8086 ° 


使 用 kubectl create 命 令 完成 创建 该 RC: 


$ kubectl create -f heapster-controller-v1.1.0.yaml 


通过 kubectl get pods--namespace-kube-systemffff YA Pod 5,2] Ji 5): 


# kubectl get deployment --namespace=kube-system 
NAME READY 
STATUS RESTARTS AGE 
heapster-v1.1.0-1895667918-guisl 4/4 


Running 0 3m 


查看 heapster 的 日 志 ， 确 保 heapster 成 功 在 influxdb 数 据 库 中 创建 名 
为 k8s 的 数据 库 : 


# kubectl logs heapster-v1.1.0-1895667918-guisl -c 
heapster --namespace=kube-system 
I0706 09:36:15.313587 1 heapster.go:65] 
/heapster -- 
source-kubernetes.summary api:'192.168.18.3:8080' -- 
sink-influxdb:http://monitoring-influxdb:8086 -- 
metric_resolution=60s 
I0706 09:36:15.313849 1 heapster.go:66] Heapster 
version 1.1.0 
I0706 09:36:15.314347 1 configs.go:60] Using 
Kubernetes client with master "https://169.169.0.1:443" and 
version "vi" 
I0706 09:36:15.314371 1 configs.go:61] Using 
kubelet port 10255 
I0706 09:36:15.512107 1 influxdb.go:223] created 
influxdb sink with options: host:monitoring-influxdb:8086 
user:root db:k8s 


I0706 09:36:15.512154 1 heapster.go:92] Starting 


with InfluxDB Sink 
I0706 09:36:15.512163 1 heapster.go:92] Starting 
with Metric Sink 
I0706 09:36:16.414060 1 heapster.go:171] 


Starting heapster on port 8082 


2) 查询 InfluxDB 数 据 库 中 的 数据 
让 我 们 先 通 过 InfluxDB 的 管理 页 面 查看 数据 。 


由 于 设置 mmfluxDB 服 务 会 又 露 到 物理 Node 节 点 上 ， 所 以 我 们 可 以 
通过 任 一 Node 的 8083 端 口 访问 InfluxDB 数 据 库 提供 的 管理 页 面 ， 如 
5.10 所 示 。 通 过 右上 角 疮 轮 按钮 可 以 修改 连接 属性 (用 于 influxdb 
service 设 置 为 非 默认 端口 号 的 时 候 ) 。 单 击 右上 角 的 Database 下 拉 列 表 
可 以 选择 数据 库 ，heapster 创 建 的 数据 库 名 为 k8s。 


Password 


5.10 Influx DB £8 Di [fi 


在 Query 输 入 框 中 输入 “SHOW MEASUREMENTS", BI a] &4 Br 
有 的 measurements (序列 表 ) 。 图 5.11 显 示 了 部 分 measurements。 


Query: | SIS mS E 


measurements 


name 
cpu/limit 

cpu/node reservation 
cpu/node utilization 
cpu/request 
cpu/usage 
cpu/usage_rate 
filesystem/available 
filesystem/limit 


filesystem/usage 


图 5.11 


Query Templates ~ 


show measurements2# Æ Ul [fij 


heapster 采 集 的 全 部 metric (性 能 指标 ) 如 表 5.6 所 示 。 


表 5.6 heapster 采 集 的 metric 


metric 名 称 


cpu/limit 


CPU hard limit， 单 位 为 毫秒 


cpu/node reservation 


Node 保留 的 CPU Share 


cpu/node utilization 


Node 的 CPU 使 用 时 间 


cpu/request 


CPU request， 单 位 为 毫秒 


cpu/usage 


全 部 Core 的 CPU 累计 使 用 时 间 


cpu/usage rate 


全 部 Core 的 CPU 崇 计 使 用 率 ， 单 位 为 坚 秘 


filesystem/usage 


文件 系统 已 用 的 空间 ， 单 位 为 字 节 


filesystem/limit 


文件 系统 总 空间 限制 ， 单 位 为 字 节 


filesystem/available 


文件 系统 可 用 的 空间 ， 单 位 为 字 节 


memory/limit 


Memory hard limit， 单 位 为 字 节 


memory/major page faults 


major page faults 数量 


memory/major page faults rate 


每 秒 的 major page faults 数量 


memory/no de re servation 


Node 保留 的 内 存 Share 


memory/node_utilization 


Node 的 内 存 使 用 值 


memory/page faults 


page faults 数量 


memory/page faults rate 


1 


每 秒 的 page faults 数量 


metric 名 称 


memory/request Memory request， 单 位 为 字 节 


memory/usage 总 内 存 使 有 


memory/working set 总 的 Working set usage, Working set 是 指 不 会 被 kernel 移 除 的 内 存 


network/rx 累计 接收 的 网 络 流量 字 节 数 


[= 1 


network/rx errors 累计 接收 的 网 错误 数 


network/rx_errors_rate 每 秒 接收 的 网 络 流量 错误 数 


network/rx_rate ,接收 的 网 络 流量 字 节 数 


network/tx 累计 发 送 的 网 络 流量 字 节 数 


network/tx_errors 累计 发 送 的 网 络 流 3 


network/tx errors rate fb AIK E 


network/tx rate 每 秒 发 送 的 网 络 流量 字 节 数 


uptime 容器 启动 总 时 长 


每 个 metric 可 以 看 作 一 张 数 据 库 表 ， 表 中 每 条 记录 由 一 组 label 组 
成 ， 可 以 看 作 字 段 ， 如 表 5.7 所 示 。 


表 5.7 ” metric 的 各 label 


Label 名 称 
pod id 系统 生成 的 Pod 唯一 名 称 
pod_name 户 指定 的 Pod 名 称 


pod_namespace Pod 所 属 的 namespace 


container_base_image 容器 的 镜像 名 称 


container_name 用 户 指定 的 容器 名 称 


host id 用 户 指定 的 Node 主机 名 
hostname 下 在 主机 名 


labels Xx 的 Label 列表 


namespace id Jr GAY namespace 的 UID 


resource id 


可 以 使 用 标准 SQL SELECT 语句 对 每 个 metric 进 行 查询 ， 例 如 查询 
CPU 的 使 用 时 间 : 


select * from "cpu/usage" limit 10 


结果 如 图 5.12 所 示 。 


cpu/usage 


1295667918 


图 5.12 ”查询 cpuusage 结 果 页 面 
3) Grafana 页 面 查 看 和 操作 


访问 Grafana 服 务 需 要 通过 Master 代 理 模 式 进 行 访问 ，URL 地 址 为 
http://192.168.18.3 ; 8080/api/v1/proxy/namespaces/kube- 


system/services/monitoring-grafana/ ° 


在 grafana 主 页 可 以 查看 监控 数据 的 图 表 展 示 画 面 。 如 图 5.13 所 示 
为 Cluster 集 群 的 整体 信息 ， 以 折线 图 的 形式 展示 了 集群 范围 内 各 Node 
的 CPU 使 用 率 、 内 存 使 用 情况 等 信息 。 


图 5.13 Grafana Cluster! f il H 


图 5.14 显 示 的 是 所 有 Pod 的 信息 ， 以 折线 图 的 形式 展示 了 集群 范围 
内 各 Pod 的 CPU 使 用 率 、 内 存 使 用 情况 、 网 络 流量 、 文 件 系统 使 用 情况 


Ate 人 
等 信息 。 


图 5.14 Grafana Pod 监 探 页 面 


Grafana 页 面 上 的 每 个 儿 表 都 可 以 进行 编辑 ， 在 标题 上 单 击 鼠标 ， 
点 击 “PEdit" 进 入 编辑 页 面 ， 可 以 对 每 个 metric 进 行 个 性 化 设置 ， 例 如 得 


询 的 表 名 、 字 段 名 、 汇 总 计算 等 ， 如 图 5.15 所 示 。 


图 5.15 ”编辑 折线 图 


到 此 ， 基 于 heapster+influxdb+grafana 的 Kubernetes 集 群 监 探 系统 就 
搭建 完成 了 。 


5.1.7 ”kubelet 的 垃圾 回收 (GC) 机 制 


Kubernetes 集 群 中 的 垃圾 回收 (Garbage Collection， 简 称 GC) 机 
制 由 kubelet 完 成 。kubelet 定 期 清理 不 再 使 用 的 容器 和 镜像 ， 每 分 钟 进 
行 一 次 容器 GC 操作 ， 每 5 分 钟 进行 一 次 镜像 GC 操作 。 


1. 容 器 (Container) 的 GC 设置 


能 够 被 GC 清理 的 容器 只 能 是 仅 由 kubelet 管 理 的 容器 。 在 kubelet 所 
在 的 Node 上 直接 通过 docker run 创 建 的 容器 将 不 会 被 kubelet 进 行 GC 清 
理 操作 。 


kubelet 的 以 下 3 个 启动 参数 用 于 设置 容器 GC 的 条 件 。 


e --minimum-container-ttl-duration: 已 停止 的 容器 在 被 清理 之 前 的 最 
小 存活 时 间 ， 例 如 “300ms”10s” 或 “2h45m”， 超 过 此 存活 时 间 的 容 
妖 将 被 标记 为 可 被 GC 清理 ， 默 认 值 为 1 分 钟 。 

e --maximum-dead-containers-per-container: 以 Pod 为 单位 的 可 以 保 
留 的 已 停止 的 (属于 同一 Pod 的 ) 容器 集 的 最 大 数量 。 有 时 ，Pod 
中 容 絮 运行 失败 或 者 健康 检查 失败 后 ， 会 被 kubelet 目 动 重启 ， 这 
将 产生 一 些 停 目的 容器 。 默 认 值 为 2。 

e --maximum-dead-containers: 在 本 Node 上 保留 的 已 停止 容 辟 的 最 
大 数量 ， 由 于 停止 的 容 需 也 会 消耗 磁盘 空间 ， 所 以 超过 该 上 限 以 
Ja, kubelet? El 2/78 £8 C. f: IER Aa DAE CE AIR], BRU EN 
240 ° 


如 有 果 需 要 关闭 针对 容器 的 GC 操作 ， 则 可 以 将 --minimum-container- 
ttl-duration 设 置 为 0， 将 --maximum-dead-containers-per-container 和 -- 


maximum-dead-containersi& E 7j ffi 2. ° 


2. 镜 像 (Image) 的 GC 设置 


Kubernetes 系 统 中 通过 imageController 和 kublet 中 集成 的 cAdvisor 共 
同 管理 镜像 的 生命 周期 ， 主 要 根据 本 Node 的 人 磁盘 使 用 率 来 触发 镜像 的 
GC 操作 。 


kubelet 的 以 下 3 个 局 动 参数 用 于 设置 镜像 GC 的 条 件 。 


e --minimum-image-ttl-duration: 不 再 使 用 的 镜像 在 被 清理 之 前 的 最 
小 存活 时 间 ， 例 如 “300ms”10s” 或 “24h45m”， 超 过 此 存活 时 间 的 镜 
像 被 标记 为 可 被 GC 清理 ， 默 认 值 为 两 分 钟 。 

e --image-gc-high-threshold: 当 人 磁盘 使 用 率 达 到 该 值 时 ， 触 发 镜像 
的 GC 操作 ， 默 认 值 为 900% 。 

e --image-gc-low-threshold: 5 RiR f Hj RENAE, GCE 
R, BAV TR 78096 ° 


删除 镜像 的 机 制 为 ， 当 磁盘 使 用 率 达 到 image-gc-high-threshold 

(例如 90%) 时 触发 ，GC 操 作 从 最 久未 使 用 (Least Recently Used) 的 

镜像 开始 删除 ， 直 到 磁盘 使 用 率 降 为 image-gc-low-threshold (例如 
8096) 或 没有 镜像 可 删 为 止 。 


5.2 Kubernetes A KRW 


本 廊 将 对 ElasticSearch 日 志 管 理 平台 的 部 署 、Cassandra 集 群 的 部 
署 及 Kubernetes 中 容 絮 的 高 级 应 用 进行 说 明 。 


5.2.1 ElasticSearch 日 志 搜 集 查 询 和 展现 案例 


在 Kubernetes 集 群 环 境 中 ， 一 个 完整 的 应 用 或 服务 都 会 涉及 为 数 
众多 的 组 件 运 行 ， 各 组 件 所 在 的 Node 及 实例 数量 都 是 可 变 的 。 日 志 
系统 如 果 不 做 集中 化 管理 ， 则 会 给 系统 的 运 维 文 撑 造成 很 大 的 困难 ， 
因此 有 必要 在 集群 层面 对 日 志 进 行 统 一 的 收集 和 检索 等 工作 。 


容器 中 输出 到 控制 台 的 日 志 ， 都 会 以 *-jsonlog 的 命名 方式 保存 
在 /var/ib/docker/containers/ 目 好 之 下 ， 这 样 束 给 了 我 们 进行 日 志 采 集 
和 后 续 处 理 的 基础 。 


Kubernetes## #4 2€. FH Fluentd+ElasticSearch+Kibana5t BY XT H zs HJ 2k 
集 、 查 询 和 展现 工作 。 


在 部 署 系 统 之 前 ， 需 要 以 下 两 个 前 提 条 件 。 


。 API Server EMALE. T CAWR ° 
。 DNS 服务 启动 运行 。 


LAS ARTA 


系统 的 逻辑 架构 如 图 5.16 所 示 。 


my ua 


在 各 Node E 34 fT — ^^ Fluentd Z 88 , o 7k P 5 /var/log 
和 /var/lib/docker/containers 两 个 目录 下 的 日 志 进 程 采 集 ， 然 后 汇总 到 
ElasticSearch 和 集群 ， 最 终 通 过 Kibana 完 成 和 用 户 的 交互 工作 。 


这 里 有 一 个 特殊 的 需求 ，Fluentd 必 须 在 每 个 Node 上 运行 一 份 ， 为 
了 满足 这 一 需要 ， 我 们 有 以 下 儿 种 不 同 的 方式 来 部 署 Fluentd 。 


。 和 直接 在 Node 主 机 上 部 署 Fluentd ° 


。 利用 kubelet 的 --config 参 数 ， 为 每 个 Node 加 载 Fluentd Pod ° 
。 利 用 DaemonSet 来 让 FluentdPod 在 每 个 Node 上 运行 。 


C rono 
/var/lib/docker/containers 


Node A 


ro —}~- 


Elastic 集群 


索引 和 查询 


| /var/lib/docker/containers |] 


| Node B 
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目前 官方 推荐 的 包括 Fluentd、Logstash 等 日 志 或 者 监控 类 的 Pod 的 
运行 方式 就 是 DaemonSet 方 式 ， 因 此 本 节 我 们 也 以 这 一 方式 进行 配 
置 o 


2. 创 建 ElasticSearch RC 和 Service 


ElasticSearchH JRCAIServiceXE X.: 


elasticsearch-rc-svc.yml 


apiVersion: v1 


kind: ReplicationController 
metadata: 
name: elasticsearch-logging-v1 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 2 
selector: 
k8s-app: elasticsearch-logging 
version: vi 
template: 
metadata: 
labels: 
k8s-app: elasticsearch-logging 
version: vi 


kubernetes.io/cluster-service: "true" 


spec: 
containers: 
- image: 
gcr.io/google containers/elasticsearch:1.8 
name: elasticsearch-logging 
resources: 
# keep request = limit to keep this 


container in guaranteed class 


limits: 


cpu: 100m 
requests: 
cpu: 100m 
ports: 


- containerPort: 9200 
name: db 
protocol: TCP 
- containerPort: 9300 
name: transport 
protocol: TCP 
volumeMounts: 
- name: es-persistent-storage 
mountPath: /data 
volumes: 
- name: es-persistent-storage 
emptyDir: {} 
apiVersion: v1 
kind: Service 
metadata: 
name: elasticsearch-logging 
namespace: kube-system 
labels: 
k8s-app: elasticsearch-logging 
kubernetes.io/cluster-service: "true" 


kubernetes.io/name: "Elasticsearch" 


spec: 

ports: 

- port: 9200 
protocol: TCP 
targetPort: db 

selector: 


k8s-app: elasticsearch-logging 


执行 kubectl create-f elastic-search.yml 命 令 完 成 创建 。 


命令 成 功 执行 后 ， 首 先 验证 Pod 的 运行 情况 。 通 过 kubectl get pods- 
-namespaces=kube-system 获 取 运 行 中 的 Pod: 


# kubectl get pods --namespaces=kube-system 


NAMESPACE NAME 
READY STATUS RESTARTS AGE 
kube-system elasticsearch-logging-v1-59qvp 1/1 
Running 0 18h 
kube-system elasticsearch-logging-vi-xnv14 1/1 
Running 0 18h 


接 下 来 通过 ElasticSearch 的 页 面 验 证 其 功能 
执行 #kubect] cluster-info 命 令 获 取 ElasticSearch 服 务 的 地 址 : 


# kubectl cluster-info 


Elasticsearch is running at 


http://192.168.18.3:8080/api/vi/proxy/namespaces/kube- 


system/services/elasticsearch-logging 


接 下 来 使 用 #kubectl proxy 命 令 对 apiserver 进 行 代理 ， 成 功 执行 后 
输出 如 下 : 


# kubectl proxy 


Starting to serve on 127.0.0.1:8001 


这 样 我 们 就 可 以 在 浏览 器 上 访问 URL 地 址 http://192.168.18.3: 


8001/api/v1/proxy/namespaces/kube-system/services/elasticsearch- 


logging， 来 验证 ElasticSearch 的 运行 情况 了 ， 返 回 的 内 容 是 一 个 JSON 
文档 : 

{ 

"status": 200, 

"name": "Emplate", 

"cluster_name": "kubernetes-logging", 


"version": { 
"number": "1.5.2", 
"build_hash": 
"62ff9868b4c8a0c45860bebb259e21980778abí1c", 
"build timestamp": "2015-04-27T09:21:06Z", 
"build snapshot": false, 


"lucene version": "4.10.4" 


ty 


"tagline": "You Know, for Search" 


j 


3. 在 每 个 Node 上 启动 Fluentd 


Fluentd 的 DaemonSet 定 义 如 下 : 


fluentd-ds.yml 


apiVersion: extensions/vibeta1 
kind: DaemonSet 
metadata: 
name: fluentd-cloud-logging 
namespace: kube-system 


labels: 
k8s-app: fluentd-cloud-logging 


spec: 
template: 
metadata: 
namespace: kube-system 
labels: 
k8s-app: fluentd-cloud-logging 
spec: 


containers: 
- name: fluentd-cloud-logging 


image: gcr.io/google containers/fluentd- 


elasticsearch:1.17 


resources: 
limits: 
cpu: 100m 
memory: 200Mi 
env: 
- name: FLUENTD ARGS 
value: -q 
volumeMounts: 
- name: varlog 
mountPath: /var/log 
readOnly: false 
- name: containers 
mountPath: /var/lib/docker/containers 
readOnly: false 
volumes: 
- name: containers 
hostPath: 
path: /var/lib/docker/containers 
- name: varlog 
hostPath: 


path: /var/log 


M 


通过 kubectl create fis > fl] ZFluentdZ 23: 


# kubectl create -f fluentd-ds.yml 


查看 创建 的 结 采 : 


# kubectl get daemonset 

NAME DESIRED CURRENT NODE - 
SELECTOR AGE 

fluentd-cloud- logging 3 3 «none» 
1h 


# kubectl get pods 
NAMESPACE NAME READY 


STATUS RESTARTS AGE 


fluentd-cloud-logging-7tw9z 1/1 
Running 0 18h 

fluentd-cloud-logging-aqdn1 1/1 
Running 0 18h 

fluentd-cloud-logging-o4usx 1/1 
Running 0 18h 


结果 显示 Fluentd DaemonSet 正 常 运行 ， 启 动 3 个 Pod， 与 集群 中 的 
Node 数 量 一 致 。 


接 下 来 ， 使 用 二 ubectl logsfluentd-cloud-logging-7tw9z 命 令 查 看 Pod 
的 日 志 ， 在 ElasticSearch 正 党 工作 的 情况 下 ， 我 们 会 看 到 类 似 下 面 这 样 
的 Eos JD 内 容 : 


# kubectl logs fluentd-cloud-logging-7tw9z 
Connection opened to Elasticsearch cluster => 
{:host=>"elasticsearch-logging", :port=>9200, 


:scheme=>"http"} 


说 明 Fluentd 与 ElasticSearch 已 经 正确 建立 了 连接 。 


4. 运 行 Kibana 
到 此 我 们 已 经 运行 了 ElasticSearch 和 Fluentd， 数 据 的 采集 和 汇聚 过 
程 已 经 完成 ， 接 下 来 束 是 使 用 Kibana 来 展示 和 操作 数据 了 。 


Kibana 的 RC 和 Service 定 义 如 下 : 


kibana-rc-svc.yml 
apiVersion: vi 
kind: ReplicationController 
metadata: 
name: kibana-logging-vi 
namespace: kube-system 
labels: 
k8s-app: kibana-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 
replicas: 1 
selector: 
k8s-app: kibana-logging 
version: vi 
template: 


metadata: 


labels: 
k8s-app: kibana-logging 
version: vi 
kubernetes.io/cluster-service: "true" 
spec: 
containers: 
- name: kibana-logging 
image: gcr.io/google containers/kibana:1.3 
resources: 
# keep request = limit to keep this 
container in guaranteed class 
limits: 
cpu: 100m 
requests: 
cpu: 100m 
env: 
- name: "ELASTICSEARCH URL" 
value: "http://elasticsearch-logging:9200" 
ports: 
- containerPort: 5601 
name: ui 
protocol: TCP 
apiVersion: v1 
kind: Service 
metadata: 


name: kibana-logging 


namespace: kube-system 

labels: 
k8s-app: kibana-logging 
kubernetes.io/cluster-service: "true" 
kubernetes.io/name: "Kibana" 

spec: 

ports: 

- port: 5601 
protocol: TCP 
targetPort: ui 

selector: 


k8s-app: kibana-logging 


通过 kubect create-f kibana-rc-svc.yml ft; 4 8) && Kibana 的 RC 和 


Service: 


# kubectl create -f kibana-rc-svc.yml 
replicationcontroller "kibana-logging-vi" created 


service "kibana-logging" created 


查看 Kibana 的 运行 情况 : 


# kubectl get pods 
NAMESPACE NAME READY 
STATUS RESTARTS AGE 
default kibana-logging-vi-oi1akg 1/1 


Running 0 1h 


# kubectl get svc 
NAME CLUSTER- IP EXTERNAL - IP 
PORT(S) AGE 
kibana-logging 169.169.195.177 «none» 


5601/TCP 1h 


# kubectl get rc 


NAME DESIRED CURRENT 
AGE 
kibana-logging-v1 1 1 1h 
结果 表明 运行 均 已 成 功 。 通 过 kubectl cluster-info fj 4 3k AL Kibana 
服务 的 URL 地 址 : 


# kubectl cluster-info 
Kibana is running at 
http://127.0.0.1:8080/api/v1/proxy/namespaces/kube- 


system/services/kibana-logging 


同样 通过 kubectl proxy A SASIR, Æ H Starting to serve on 
127.0.0.1: 8001 字 样 之 后 ， 用 浏 蜗 豆 访问 URL 地 址 即 可 访问 Kibana 页 
面 了 :  http//192.168.18.3 : — 8001/api/vl/proxy/namespaces/kube- 


system/services/kibana-logging ° 


第 1 次 进入 页 面 需要 进行 一 些 设置 ， 如 图 5.17 所 示 ， 选 择 所 需 选 项 
后 单 击 create。 


Vll Settings - Kibane 39 pl Settings - Kibara 4 
€ ec 


10.255.242 214:1171/£/settings/indices/? g=0 ayes 


Discovo f hboard ^ Sctings 


Index Patterns 


Ri Configure an index pattern 


continue 
In order to use Kibana you must configure at least one index pattern. Index patterns aro used to identify the Elasticsearch index to run search and analytics against. They are also used to 


configure fields. 


Index contains time-based events 


| Use event times to create index names 


Index name or pattorn 


Patlerns allow you to define dynamic index names using * as a wildcard Example’ logstash- 


logstash-* 


Time field name @ revesn nalas 


Hc ———'Üi] 


人 @bmestamp 


"oo 0m U 0o 
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然后 单 击 discover， 就 可 以 正常 查询 日 志 了 ， 如 图 5.18 所 示 。 


JU Discover - bora 4 


C [E 10.255.242.214 


| e ana Discover v 


auto,query:(query_string:(analyze_wildcard 


1171/£/discover 


olumns:( source) index-logstash- 


Dashboard 。 Seungs 


3,437 hits 
March 23rd 2016, 15:58:15.811 - March 23rd 2016, 


Selected Fields 


„source 


o 
Fields a 
Popular folcs 3 
E Count 115 
@ivestamp o 
155 5 o 16060 T X 100 16:11:00 


@timestamp por 30 seconds March 23rd 2016, 15 
60720 16 


"cunt 


id &ümestamp per 30 seconds 
index P: 
-tve 
Time » source 
109 
es + Narch 23rd 2016, 16:11:15.000 Á— severity E pid: 7616 seuree: pod workers.g0:138 message: Error syncing pod 4b382947-eFlc-11e5-8cd0-144842254fde, ski 
stream 
pping: failed to "StartContainer" for “container-O" with ImagePullBackOff: "Back-off pulling image \"http://10.254.90.3 
i 1:1179/tomcat:Gl^" tag? kubelet Wüimestmp: March 23rd 2016, 16:11:15.000 sewrce: "severity": E", "pid" :"7616", "soure 
psum nod. workers. 90:138" ,"nessage":"Error syncing pod 4b3629d7 11c5-Scd0-442842254fde, skipping: failed to \"Stertc 
sovority Y 
» Narch 23rd 2016, 16:11:15.000 severity: E pid: 41740 source: pod workers.go:138 message: Error syncing pod 4a744738-eflc-11e5-8cd0-444842254fde, sk 
source 
ipping: failed to "StartContainer" For "activemq" with ImagePullBackOFf: "Back-oFF pulling image \""10.255, 242. 213:5000, 
busyoox:Tatest\"" tag: kubelet @timestenp® March 23rd 2016, 16:11:15.000 _somree: "severity: "E", "pid" :"41740","sourc 
pod workers. 90:138", "message" ror syncing pod 42744738-cf1c-11e5-8cd0-442842254fde, skipping: fai "StertC 
» March 25rd 2016; 16 7616 sewrce: pod workers.g0:138 message: Error syncing pod 4aGc299a-cFic-11e5-8cd0-440842254Fde, ski e 
-— | mr ww Y x 
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在 搜索 栏 输入 “error 天 键 字 ， 可 以 搜索 出 从 某 些 Node 上 找到 的 日 
志 记 录 ， 如 图 5.19 所 示 。 


e Œ | D 10.255.242.214:1171/#/discover?_a=(columns:!{_source),index:'logstash-*',intervalauto,query:(query _string:(analyze wildcard:!t,query-error)),sort:('@time ® y| = 


Fields a 


Popular fields. 


Bamosamp 


message 
bid 
severity 


source 


Last 18 minutes © 
a BS 


1,522 hits 


March 23rd 2016, 16:03:11.101 - March 23rd 2016, 16:18:11.101 


Count 


@umest 


mp por 30 seconds 


^ 


Time. source 


> March 23rd 2016, 16:18:11.000 message EEI syncing pod 4eb5777c-efic-11e5-8cd0-24a842254fde, skip 


: failed to "StartContainer” for severity: E 


pid: 15030 soares: pod workers.go:138 teg: kubelet Wiimectemp: March 23rd 2016, 16:18:11.000 _somree: ("severit 


y" E," pid" 115030", "source" :^pod workers.go:138",'message":"Error syncing pod 42b6777c-cflc-11e5 -Scd0-44a842254fde, s 


kipping: failed to \"StartContainer\" for \"activena\,” 


with ImagePullBackOff: ^"Back-off pulling image \\"L0.255.242.2 


> March 23rd 2 


6, 16:18:11.000 geceage> EB syncing pod aas0sQDe-efic-l1e5-5cdo-24as22254fde, skipping: failed to “Startcontainer” for severity: E 


pid: 37777 souree: pod workers.go:138 tag: kubelet timestamp: March 23rd 2016, 16:18:11.000 _soaree: {"severit 


pid" :"'37777", “source” :"pod_norkers.go:138",""message":"Crror syncing pod 4a90500e-ef1c-11e5-8cd0-44a842254fde, 


kipping: failed to \"StartContainer\" for \"activena\” with ImagePullBackOf: \"Back-off pulling image \\\"10.25: 


» March 23rd 2016, 16:18:11.000 【ES NNNM syncing pod 42741733-efic-11e5-8cdO-44a842254fde, skipping: failed to "startcontainer" for severi 


同时 ， 通 过 
如 图 5.20 所 示 。 


n — cá [=a ur T T 


图 5.19 ”Kibana 日 志 关 键 字 搜索 页 面 
边 菜 单 中 Fields 相 天 的 内 容 对 查询 的 内 容 进行 
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至 此 ，Kubernetes 集 群 范 围 内 的 统一 日 志 收 集 和 查询 系统 就 搭建 
TRT ° 


5.2.2 Cassandra 集 群 部 署 案 例 


Apache Cassandra 是 一 套 开源 分 布 式 NoSQL 数 据 库 系 统 ， 其 主要 特 

点 束 是 它 不 是 单个 数据 库 ， 而 是 由 一 组 数据 库 节 点 共同 构成 的 一 个 分 

ti XB HPA o h T Cassandrafs AWE“ HUD Least, BEL d 

集群 里 的 一 个 节点 局 动 之 后 需要 一 个 途径 获知 集群 中 新 节点 的 加 入 。 

Cassandra 使 用 了 Seed (种 子 ) 的 概念 来 完成 在 集群 中 节点 之 间 的 相互 
查找 和 通信 


本 例 通 过 对 Kubernetes 中 Service 概 念 的 巧妙 使 用 实现 了 各 
Cassandra I? A Z BASHE EFR 9 


1. H xe X SeedProvider 


在 本 例 中 使 用 了 一 个 自 定 义 的 SeedProvider 类 来 完成 新 节点 的 查询 
和 添加 ， 类 名 为 io.k8s.cassandra.KubernetesSeedProvider ° 


KubernetesSeedProvider.java 类 的 源 代 码 节 选 如 下 : 


public List<InetAddress> getSeeds() { 
List<InetAddress> list = new 
ArrayList<InetAddress>(); 
String host = 


"https://kubernetes.default.cluster.local"; 


String serviceName = 
getEnvOrDefault("CASSANDRA SERVICE", "cassandra" ); 
String  podNamespace = 
getEnvOrDefault("POD NAMESPACE", "default"); 

String path - 
String.format("/api/vi/namespaces/%s/endpoints/", 
podNamespace); 

public static void main(String[] args) { 
SeedProvider provider = new 
KubernetesSeedProvider (new HashMap<String, String»()); 


System.out.println(provider.getSeeds()); 


cs X Hy RK BT D OAM x B X NE 
http://kubernetes.io/v1.0/examples/cassandra/java/src/io/k8s/cassandra/Kub 


ernetesSeedProvider.java 


创建 Cassandra Pod 的 配置 文件 如 下 : 


cassandra.yaml 


apiVersion: v1 

kind: Pod 

metadata: 
labels: 


name: cassandra 


name: cassandra 
spec: 
containers: 
- args: 
- /run.sh 
resources: 
limits: 
cpu: "0.5" 
image: gcr.io/google_containers/cassandra:v5 
name: cassandra 
ports: 
- name: cql 
containerPort: 9042 
- name: thrift 
containerPort: 9160 
volumeMounts: 
- name: data 
mountPath: /cassandra_data 
env: 
- name: MAX_HEAP_SIZE 
value: 512M 
- name: HEAP_NEWSIZE 
value: 100M 
- name: POD_NAMESPACE 
valueFrom: 
fieldRef: 


fieldPath: metadata.namespace 


volumes: 
- name: data 


emptyDir: {} 


需要 说 明 的 是 ， 在 镜像 gcr.io/google_containers/cassandra: v5 中 安 
装 了 一 个 标准 的 Cassandra 应 用 程序 ， 并 将 定制 的 SeedProvider 类 一 -一 
KubernetesSeedProvider 打 包 到 镜像 中 了 。 


定制 的 KubernetesSeedProvider 类 将 使 用 REST API 来 访问 
Kubernetes Master, ， 然 后 通过 查询 name=cassandra 的 服务 指向 的 Pod 来 
完成 对 其 他 “节点 ”的 查找 。 


2. 通 过 Service 动 态 查 找 Pod 


在 KubernetesSeedProvider 类 中 , 通过 查询 环境 变量 
CASSANDRA_SERVICE 的 值 来 获得 服务 的 名 称 。 这 样 束 要 求 Service 
需要 在 Pod 之 前 创建 出 来 。 如 果 我 们 已 经 创建 好 DNS 服务 (参见 5.1 节 
的 案例 介绍 ) ， 那 么 也 可 以 直接 使 用 服务 的 名 称 而 无 须 使 用 环境 变 


HÆ ° 


回顾 一 下 Service 的 概念 。Service 通 常用 作 一 个 负载 均衡 器 ， 供 
Kubernetes 集 群 中 其 他 应 用 (Pod) 对 属于 该 Service 的 一 组 Pod 进 行 访 
问 。 由 于 Pod 的 创建 和 销毁 都 会 实时 更 新 Service 的 Endpoints 数 据 ， 所 
以 可 以 动态 地 对 Service 的 后 端 Pod 进 行 查 询 了 。Cassandra 的 “去 中 心 
化 ”设计 使 得 Cassandra 集 群 中 的 一 个 Cassandra 实 例 (节点 ) 只 需要 查 
询 到 其 他 节点 ， 即 可 自动 组 成 一 个 集群 ， 正 好 可 以 使 用 Service 的 这 个 
特性 查询 到 新 增 的 节点 。 图 5.21 描 述 了 Cassandra 新 广 点 加 入 集群 的 过 
程 。 


Kubernetes 
Master 


2. 获取 Service 的 
后 端 Endpoint， 将 
新 Pod 加 入 和 集群 


2. 获取 Service 的 
后 端 Endpoint， 将 
新 Pod 加 入 和 集群 


— — 


Cassandra 


= Nod 
p 1, FH ROEM, d 
将 更 新 Service 的 
Cassandra EnGpON! l 
». / 
h 7 
Vd 
ss NEW : 
Cassandra _ Cassandra | 
Node 


‘ 
Node y 


5.21 Cassandra#t T SJ A REA TE 


f£ Kubernetes 系统 中 ， 首 先 需 要 为 Cassandra 集 群 定义 一 个 


Service ° 


cassandra-service.yaml: 


apiVersion: v1 
kind: Service 
metadata: 
labels: 
name: cassandra 
name: cassandra 
spec: 


ports: 


- port: 9042 
selector: 


name: cassandra 


在 Service 的 定义 中 指定 Label Selector Yname=cassandra ° 


(1) 创建 Service: 


$ kubectl create -f cassandra-service.yaml 


(2) 创建 一 个 Cassandra Pod: 


$ kubectl create -f cassandra-pod.yaml 


现在 ， 一 个 名 为 cassandra 的 Pod 运 行 起 来 了 ， 但 还 没有 组 成 
Cassandra 和 集群 。 


(3) 创建 一 个 RC 来 控制 pod 集群 : 
cassandra-controller.yaml 


apiVersion: v1 
kind: ReplicationController 
metadata: 
labels: 
name: cassandra 
name: cassandra 


spec: 


replicas: 1 
selector: 
name: cassandra 
template: 
metadata: 
labels: 
name: cassandra 
spec: 
containers: 
- command: 
- /run.sh 
resources: 
limits: 
cpu: 0.5 
env: 
- name: MAX_HEAP_SIZE 
value: 512M 
- name: HEAP_NEWSIZE 
value: 100M 
- name: POD_NAMESPACE 
valueFrom: 
fieldRef: 
fieldPath: metadata.namespace 
image: gcr.io/google containers/cassandra:vb5 
name: cassandra 
ports: 


- containerPort: 9042 


name: cql 

- containerPort: 9160 
name: thrift 

volumeMounts: 

- mountPath: /cassandra_data 

name: data 
volumes: 
- name: data 


emptyDir: {} 


由 于 在 RC 定 义 中 指定 的 replicas 数 量 为 1， 所 以 创建 RC 后 ， 仍 然 只 
有 之 前 创建 的 那个 名 为 cassandra 的 Pod 在 运行 。 
3.Cassandra 集 群 中 狐 市 点 的 目 动 添加 


现在 ， 我 们 使 用 Kubernetes 提 供 的 Scale (动态 缩放 ) 机 制 对 
Cassandra 集 群 进行 扩容 : 


$ kubectl scale rc cassandra --replicas=2 


查看 Pod， 可 以 看 到 RC 创建 并 启动 了 一 个 新 的 Pod: 


$ kubectl get pods -1="name=cassandra" 
NAME READY STATUS RESTARTS AGE 
cassandra 1/1 Running 0 5m 


cassandra-g52t3 1/1 Running 0 50s 


使 用 Cassandra 提 供 的 nodetool 工 具 对 任 一 cassandra 实 例 (Pod) xf 
行 访问 来 验证 Cassandra 集 群 的 状态 。 下 面 的 命令 将 访问 名 为 cassandra 
的 Pod (访问 cassandra-g52t3 也 能 获得 相同 的 结果 ) : 


$ kubectl exec -ti cassandra -- nodetool status 


Datacenter: datacenter1 


Status-Up/Down 


|/ State=Normal/Leaving/Joining/Moving 


-- Address Load Tokens Owns (effective) 
Host ID Rack 
UN 10.1.20.16 51.58 KB 256 100.0% 


1625c65d-b5b6-40f4-a794-6f5a12322d86 racki 
UN 10.1.10.11 51.51 KB 256 100 . 0% 


cdfcbfia-795c-4412-9d3f-e8fe50bb8deb rack 


可 以 看 到 Cassandra 集 群 中 有 两 个 节点 处 于 正常 运行 状态 (Up and 
Normal, UN) 。 结 果 中 的 两 个 IP 地 址 为 两 个 Cassandra Pod 的 IP 地 址 。 


内 部 的 过 程 为 : 个 Cassandra P zi (Pod) 通过 API 访 问 
Kubernetes Master, 查询 名 7j cassandra 的 Service 的 Endpoints ( HII 
Cassandra R) ， 若 发 现 有 新 和 点 加 入 ， 束 进行 添加 操作 ， 最 后 成 功 
组 成 了 一 个 Cassandra 集 群 。 


我 们 再 增加 两 个 Cassandra 实 例 ; 


$ kubectl scale rc cassandra --replicas=4 


FAnodetool T. E. £& Cassandra k BEA s: 


$ kubectl exec -ti cassandra -- nodetool status 


Datacenter: datacenter1 


Status-Up/Down 


|/ State=Normal/Leaving/Joining/Moving 


Host ID 


1625c65d- 


8bccic3e- 


579b6493- 


cdfcbfia- 


可 以 看 到 4 个 Cassandra 贡 点 都 加 入 Cassandra 集 群 中 了 。 


Address Load 
Rack 

UN 10.1.20.16 51.58 KB 256 
b5b6-40f4-a794-6f5a12322d86 rack1i 
UN 10.1.10.12 52.03 KB 256 
44ec-46a7-b981-4090b206f14e rack1i 
UN 10.1.20.17 68.05 KB 256 
e92a-47f5-91f2-9313198a24C9 rack1 
UN 10.1.10.11 51.51 KB 256 


795c-4412-9d3f-e8fe50bb8deb rack 


Tokens Owns (effective) 


50.5% 


47.0% 


50.6% 


51.9% 


另外 ， 可 以 通过 查看 Cassandra Pod 的 日 志 来 看 到 新 节点 加 入 集群 


的 记录 : 


$ kubectl logs cassandra-g52t3 


INFO 18:05:36 Handshaking version with /10.1.20.17 


INFO 


18:05:36 Node /10.1.20.17 is now part of the 


cluster 
INFO 18:05:36 InetAddress /10.1.20.17 is now UP 
INFO 18:05:38 Handshaking version with /10.1.10.12 
INFO 18:05:39 Node /10.1.10.12 is now part of the 
cluster 


INFO 18:05:39 InetAddress /10.1.10.12 is now UP 


本 例 描述 了 一 种 通过 API 查 询 Service 来 完成 动态 Pod 发 现 的 应 用 场 
景 。 对 于 类 似 于 Cassandra 集 群 的 应 用 ， 都 可 以 使 用 对 Service 进 行 查询 
后 端 Endpoints 这 种 巧妙 的 方法 来 实现 对 应 用 集群 (属于 同一 Service) 
中 新 加 入 市 点 的 查找 。 


5.3 Trouble Shootingfa = 


Ak TRES KubernetesfE 3E FFs DLE PRIH ENT TA XETT VL] 。 


为 了 跟踪 和 发 现 Kubernetes 集 群 中 运行 的 容器 应 用 出 现 的 问题 ， 
常用 的 查 错 方法 如 下 。 


自 完 ， 查 看 Kubernetes 对 象 的 当前 运行 时 信息 ， 特 别 是 与 对 象 关 
联 的 Event 事 件 。 这 些 事件 记录 了 相关 主题 、 发 生 时 间 、 最 近 发 生 时 
间 、 发 生 次 数 及 事件 原因 等 ， 对 排查 故障 非常 有 价值 。 此 外 ， 通 过 碍 
看 对 象 的 运行 时 数据 ， 我 们 还 可 以 发 现 参数 错误 、 关 联 错误 、 状 态 异 
常 等 明显 问题 。 由 于 Kubemetes 中 多 种 对 象 相互 天 联 ， 因 此 ， 这 一 步 
可 能 会 涉及 多 个 相关 对 象 的 排查 问题 。 


其 次 ， 对 于 服务 、 容 器 的 问题 ， 则 可 能 需要 深入 容器 内 部 进行 故 
障 诊断 ， 此 时 可 以 通过 查看 容器 的 运行 日 志 来 定位 具体 问题 。 


最 后 ， 对 于 某 些 复杂 问题 ， 比 如 Pod 调 度 这 种 全 局 性 的 问题 ， 可 
能 需要 结合 集群 中 每 个 和 点 上 的 Kubernetes 服 务 日 志 来 排查 。 比 如 搜 
f Master 上 kube-apiserver、kube-schedule、kube-controler-manager 服 务 
的 日 六， 以 及 各 个 Node 世 点 上 的 kubelet、kube-proxy 服 务 的 日 志 ， 绿 
合 判断 各 种 信息 ， 我 们 就 能 找到 问题 的 原因 并 解决 问题 。 


5.3.1 查看 系统 Event 事 件 


在 Kubernetes 集 群 中 创建 了 Pod 之 后 ， 我 们 可 以 通过 kubectl get 
pods 命 令 查看 Pod 列 表 ， 但 该 命令 能 够 显示 的 信息 很 有 限 。Kubernetes 
提供 了 kubectl describe pod 命 令 来 查看 一 个 Pod 的 详细 信息 。 


$ kubectl describe pod redis-master-bobrO 


Name: Redis-master-bobrO 

Namespace: default 

Image(s): kubeguide/Redis-master 
Node: k8s -node- 


1/192.168.18.3 
Labels: name-Redis- 


master, role=master 


Status: Running 

Reason: 

Message: 

IP: 172.17.0.58 
Replication Controllers: Redis-master (1/1 


replicas created) 
Containers: 
master: 
Image: kubeguide/Redis-master 


Limits: 


cpu: 250m 


memory: 64Mi 
State: Running 
Started: Fri, 21 Aug 2015 14:45:37 
+0800 
Ready: True 
Restart Count: 0 
Conditions: 
Type Status 
Ready True 
Events: 
FirstSeen LastSeen Count 
From SubobjectPath Reason Message 
Fri, 21 Aug 2015 14:45:36 +0800 Fri, 21 Aug 
2015 14:45:36 +0800 1 (kubelet k8s-node-1} 
implicitly required container POD pulled Pod 
container image 
"myregistry:5000/google_containers/pause: latest" already 


present on machine 


Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 
2015 14:45:37 +0800 1 (kubelet k8s-node-1} 
implicitly required container POD created Created 


with docker id a4aa97813908 


Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 
2015 14:45:37 +0800 1 (kubelet k8s-node-1} 
implicitly required container POD started Started 


with docker id a4aa97813908 


Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 
2015 14:45:37 +0800 1 (kubelet k8s-node-1} 
spec.containers{master } created 


Created with docker id 1e746245f768 


Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 
2015 14:45:37 +0800 1 (kubelet k8s-node-1} 
spec.containers{master } started 


Started with docker id 1e746245f768 


Fri, 21 Aug 2015 14:45:37 +0800 Fri, 21 Aug 
2015 14:45:37 +0800 1 {scheduler } 
scheduled Successfully assigned Redis-master-bobrO 


to k8s-node-1 


该 命令 除了 显示 Pod 创 建 时 的 配置 定义 、 状 态 等 信息 ， 还 显示 了 
与 该 Pod 相 关 的 最 近 的 Event 事 件 ， 事 件 信息 对 于 得 错 非 常 有 用 。 如 果 
某 个 Pod 一 直 处 于 Pending 状 态 ， 则 我 们 通过 kubectl describe SHEE T 
解 到 失败 的 具体 原因 。 例 如 ， 从 Event 事 件 中 我 们 可 能 获知 Pod 失 败 的 
原因 有 以 下 几 种 。 


。 没 有 可 用 的 Node 以 供 调度 。 

。 开 启 了 资源 配额 管理 并 且 当 前 Pod 的 目标 节点 上 恰好 没有 可 用 的 
资源 。 

。 正在 下 载 镜像 。 


kubectl describe 命 令 还 可 用 于 查看 其 他 Kubernetes 对 象 ， 包 括 
Node、RC、Service、Namespace、Secrets 等 ， 对 于 每 一 种 对 象 都 会 显 
示 相 关联 的 其 他 信息 。 
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$ kubectl describe service redis-master 


Name: Redis-master 

Namespace: default 

Labels: name=Redis-master 
Selector: name=Redis-master 

Type: ClusterIP 

IP: 169.169.208.57 

Port: <unnamed> 6379/TCP 
Endpoints: 172.17.0.58:6379 

Session Affinity: None 

No events. 


如 果 查 看 的 对 象 属于 某 个 特定 的 namespace ， 则 需要 加 上 -- 


namespace=<namespace> 进 行 查询 。 例 如 : 


$ kubectl get service kube-dns --namespace=kube-system 


53292 查看 容器 志 


在 需要 排查 容器 内 部 应 用 程序 生成 的 日 志 时 ， 我 们 可 以 使 用 
kubectl logs<pod_name> 命 令 
$ kubectl logs redis-master-bobrO 
[1] 21 Aug 06:45:37.781 * Redis 2.8.19 (00000000/0) 64 
bit, stand alone mode, port 6379, pid 1 ready to start. 
[1] 21 Aug 06:45:37.781 £ Server started, Redis 
version 2.8.19 
[1] 21 Aug 06:45:37.781 # WARNING overcommit memory is 
set to 0! Background save may fail under low memory 
condition. To fix this issue add 'vm.overcommit memory - 1' 
to /etc/sysctl.conf and then reboot or run the command 
"sysctl vm.overcommit_memory=1' for this to take effect. 
[1] 21 Aug 06:45:37.782 # WARNING you have Transparent 
Huge Pages (THP) support enabled in your kernel. This will 
create latency and memory usage issues with Redis. To fix 
this issue run the command ' echo never > 
/sys/kernel/mm/transparent_hugepage/enabled' as root, and 
add it to your /etc/rc.local in order to retain the setting 
after a reboot. Redis must be restarted after THP is 
disabled. 
[1] 21 Aug 06:45:37.782 # WARNING: The TCP backlog 


setting of 511 cannot be enforced because 
/proc/sys/net/core/somaxconn is set to the lower value of 


128. 
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称 来 进行 查看 ， 例 如 : 


kubectl logs <pod_name> -c <container_name> 


这 个 命令 与 在 Pod 的 答 主 机 上 运行 docker logs<container_id> 的 效果 
te 
是 一 样 的 。 


容 絮 中 应 用 程序 生成 的 日 志 与 容器 的 生命 周期 是 一 人 怪 的 ， 所 以 在 
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〈 存 储 卷 ) 将 容器 产生 的 日 志保 存 到 宿主 机 ， 另 一 方面 也 可 以 通过 一 
些 工 具 对 日 志 进 行 采集 ， 包 括 Fluentd、ElasticSearch 等 开源 软件 。 


5.3.3 ”查看 Kubernetes 服 务 日 志 


如 有 果 在 Linux 系 统 上 进行 安装 ， 并 且 使 用 systemd 系 统 来 管理 
aed 那么 systemd 的 journal 系统 会 接管 服务 程序 的 输出 日 

。 在 这 种 环境 中 ， 可 以 通过 使 用 systemd status 或 journalctl 工 具 来 查 
" 统 服 务 的 日 志 。 


例如 ， 使 用 systemctl status 命 令 查 看 kube-controller-manager 服 务 的 
Hs: 


# systemctl status kube-controller-manager -1 
kube-controller-manager.service -  Kubernetes 
Controller Manager 
Loaded: loaded (/usr/lib/systemd/system/kube- 
controller-manager.service; enabled) 
Active: active (running) since Fri 2015-08-21 
18:36:29 CST; 5min ago 
Docs: 
https://github.com/GoogleCloudPlatform/kubernetes 
Main PID: 20339 (kube-controller) 
CGroup:  /system.slice/kube-controller- 
manager.service 
L-20339 J /usr/bin/kube-controller-manager  -- 
logtostderr-false --V-4 --master-http://kubernetes- 


master:8080 --log dir-/var/log/kubernetes 


Aug 21 18:36:29 kubernetes-master systemd[1]: Starting 
Kubernetes Controller Manager... 
Aug 21 18:36:29 kubernetes-master systemd[1]: Started 


Kubernetes Controller Manager. 


使 用 journalcd 命 令 查 看 : 


# journalctl -u kube-controller-manager 
-- Logs begin at Mon 2015-08-17 16:43:22 CST, end at 
Fri 2015-08-21 18:36:29 CST. -- 
Aug 17 16:44:14 kubernetes-master systemd[1]: Starting 
Kubernetes Controller Manager... 
Aug 17 16:44:14 kubernetes-master systemd[1]: Started 


Kubernetes Controller Manager. 


如 果 不 使 用 systemd 系 统 接管 Kubernetes 服 务 的 标准 输出 ， 则 也 可 
以 通过 日 志 相 关 的 启动 参数 来 指定 日 志 的 存放 目录 。 


e --logtostderr=false: 不 输出 到 stderr ° 

e --log-dir=/var/log/kubernetes: 日 志 的 存放 目录 。 

e --alsologtostderr=false: 设置 为 tue 则 表示 将 日 志 输 出 到 文件 时 也 
输出 到 stderr ° 

e --V=0: glog 日 志 级 别 。 

e --vmodule=gfs*=2, test*-4: glog 基 于 模块 的 详细 日 志 级 别 。 


在 --log_dir 设 置 的 目录 中 可 以 查看 各 服务 进程 生成 的 日 志文 件 ， 
日 志文 件 的 数量 和 大 小 依赖 于 日 志 级 别 的 设置 。 例 如 kube-controller- 


manager 可 能 生成 的 几 个 日 志文 件 如 下 。 


e kube-controller-manager.ERROR ° 

e kube-controller-manager.INFO ° 

e kube-controller-manager. WARNING ° 

e kube-controller-manager.kubernetes- 
master.unknownuser.log.ERROR.20150930-173939.9847 ° 

e kube-controller-manager.kubernetes- 
master.unknownuser.log.INFO.20150930-173939.9847 ° 

e kube-controller-manager.kubernetes- 
master.unknownuser.log.WARNING.20150930-173939.9847 ° 


在 大 多 数 情况 下 ， 我 们 从 WARNING 和 ERROR 级 别 的 日 志 中 就 能 
找到 问题 的 原因 ， 但 有 时 还 是 需要 排查 INFO 级 别 的 日 志 甚 至 DEBUG 
级 别 的 详细 日 志 。 此 外 ，etcd 服 务 也 属于 Kubernetes 集 群 中 的 重要 组 成 
部 分 ， 所 以 它 的 日 志 也 不 能 忽略 。 


如 果 是 某 个 Kubernetes 对 象 存在 问题 ， 则 我 们 可 以 用 这 个 对 象 的 
名 字 作 为 关键 字 搜 索 Kubemetes 的 日 志 来 发 现 和 解决 问题 。 在 大 多 数 
情况 下 ， 我 们 平常 所 遇 到 的 主要 是 与 Pod 对 象 相 关 的 问题 ， 比 如 无 法 
创建 Pod、Pod 启 动 后 驶 停止 或 者 Pod 副 本 无 法 增加 等 。 此 时 ， 我 们 可 
以 先 确 定 Pod 在 哪个 节点 上 ， 然 后 登录 这 个 下 点 ， 从 kubelet 的 日 志 中 碍 
询 该 Pod 的 完整 日 志 ， 然 后 进行 问题 排查 。 对 于 与 Pod 扩 容 相 关 或 者 与 
RC 相关 的 问题 ， 则 很 可 能 在 kube-controller-manager 及 kube-scheduler 的 ] 
日 志 上 找 出 问题 的 关键 点 。 


另外 ，kube-proxy 经 常 被 我 们 忽视 ， 因 为 即使 它 意外 地 被 停止， 
Pod 的 状态 也 是 正常 的 ， 但 会 导致 某 些 服务 访问 异常 的 情况 。 这 些 错 
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1. 由 于 无 法 下 载 pause 镜 像 导 致 Pod 一 直 处 于 Pending 的 状态 


以 redis-master 为 例 ， 使 用 如 下 配置 文件 redis-master-controller.yaml 
创建 RC 和 Pod: 


apiVersion: vi 
kind: ReplicationController 
metadata: 
name: redis-master 
labels: 
name: redis-master 
spec: 
replicas: 1 
selector: 
name: redis-master 
template: 
metadata: 
labels: 
name: redis-master 


spec: 


containers: 

- name: master 
image: kubeguide/redis-master 
ports: 


- containerPort: 6379 


执行 kubectl create-f redis-master-controller.yaml AKL ° 


但 在 查看 Pod 时 ， 发 现 其 总 是 无 法 处 于 Running 状 态 。 通 过 kubectl 
get pods 命 令 可 以 看 到 : 
$ kubectl get pods 
NAME READY STATUS 
RESTARTS AGE 
redis-master-6yy70 0/1 Image: kubeguide/redis- 
master is ready, container is creating 0 5m 


进一步 使 用 kubectl describe pod redis-master-6yy7o 命 令 查 看 该 Pod 


的 详细 信息 Pr 


$ kubectl describe pod redis-master-6yy70 


Name: redis-master-6yy70 
Namespace: default 

Image(s): kubeguide/redis-master 
Node: 127.0.0.1/127.0.0.1 
Labels: name-redis-master 


Status: Pending 


Reason: 
Message: 
IP: 
Replication Controllers: redis-master (1/1 


replicas created) 


Containers: 
master: 
Image: kubeguide/redis-master 
State: Waiting 
Reason: Image: kubeguide/redis-master 


is ready, container is creating 


Ready: False 
Restart Count: 0 
Conditions: 
Type Status 
Ready False 
Events: 
FirstSeen LastSeen Count 
From SubobjectPath Reason Message 
Thu, 24 Sep 2015 19:19:25 +0800 Thu, 24 Sep 
2015 19:25:58 +0800 3 (kubelet 127.0.0.1} 


failedSync Error syncing pod, skipping: image pull failed 
for gcr.io/google containers/pause-amd64:3.0, this may be 
because there are no credentials on this request. details: 
(API error (500): invalid registry endpoint 
https://gcr.io/v0/: unable to ping registry endpoint 


https://gcr.io/vO/v2 ping attempt failed with error: Get 


https://gcr.io/v2/: dial tcp 173.194.196.82:443: connection 
refused v1 ping attempt failed with error: Get 
https://gcr.10/vi/_ping: dial tcp 173.194.79.82:443: 
connection refused. If this private registry supports only 
HTTP or HTTPS with an unknown CA certificate, please add `- 
-insecure-registry gcr.io to the daemon's arguments. In 
the case of HTTPS, if you have access to the registry's CA 
certificate, no need for the flag; simply place the CA 
certificate at /etc/docker/certs.d/gcr.io/ca.crt) 

Thu, 24 Sep 2015 19:19:25 +0800 Thu, 24 Sep 
2015 19:25:58 +0800 3 (kubelet 127.0.0.1} 
implicitly required container POD failed Failed to pull 
image "gcr.io/google containers/pause-amd64:3.0": image 
pull failed for gcr.io/google containers/pause:0.8.0, this 
may be because there are no credentials on this request. 
details: (API error (500): invalid registry endpoint 
https://gcr.io/v0/: unable to ping registry endpoint 
https://gcr.io/vO/v2 ping attempt failed with error: Get 
https://gcr.io/v2/: dial tcp 173.194.196.82:443: connection 
refused v1 ping attempt failed with error: Get 
https://gcr.10/vi/_ping: dial tcp 173.194.79.82:443: 
connection refused. If this private registry supports only 
HTTP or HTTPS with an unknown CA certificate, please add `- 
-insecure-registry gcr.io to the daemon's arguments. In 
the case of HTTPS, if you have access to the registry's CA 
certificate, no need for the flag; simply place the CA 


certificate at /etc/docker/certs.d/gcr.io/ca.crt 


可 以 看 到 ， 该 Pod 的 状态 为 Panding， 从 Message 部 分 显示 的 信息 可 
以 看 出 其 原因 是 image pull failed for gcrio/google_containers/pause- 
amd64: 3.0， 说 明 系 统 在 创建 Pod 时 无 法 从 gcrio 下 载 pause 镜 像 ， 所 以 
导致 创建 Pod 失 败 。 


解决 方法 如 下 。 


(1) 如 果 服 务 器 可 以 访问 Internet， 并 且 不 希望 使 用 HTTPS 的 安 
全 机 制 来 访问 gcrio， 则 可 以 在 Docker Daemon 的 启动 参数 中 加 上 -- 
insecure-registry gcrio 来 表示 可 以 进行 匿名 下 载 。 


(2) 如 果 Kubernetes 集 群 环 境 在 内 网 环境 中 ， 无 法 访问 gcrio 网 
站 ， 则 可 以 先 通 过 一 人 台 能 够 访问 gcrio 的 机 吉 将 pause 镜 像 下 载 下 来 ， 导 
出 后 ， 再 导入 内 网 的 Docker 私 有 镜像 库 中 ， 并 在 kubelet 的 局 动 参数 中 
加 上 --pod_infra_container_image， 配 置 为 : 


--pod_infra_container_image=<docker_registry_ip>: 


<port>/google_containers/pause-amd64:3.0 


之 后 重新 创建 redis-master 即 可 正确 局 动 Pod 了 » 


注意 ， 除 了 pause 镜 像 ， 其 他 Docker 镜 像 也 可 能 存在 无 法 下 载 的 情 
况 ， 与 上 述 情 况 类 似 ， 很 可 能 也 是 网 络 配 置 使 得 镜像 无 法 下 载 ， 解决 
方法 同上 。 


2.Pod 创 建成 功 ， 但 状态 始终 不 是 Ready， 且 RESTARTS 的 数量 持 


在 创建 了 一 个 RC 之 后 ， 通 过 kubectl get pods 命 令 查 看 Pod， 发 现 如 


$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 
zk-bg-ri3ru 0/1 Running 3 37s 

$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 
zk-bg-ri3ru 0/1 Running 5 im 

$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 
zk-bg-ri3ru 0/1 ExitCode:0 6 im 
$ kubectl get pods 

NAME READY STATUS RESTARTS AGE 


zk-bg-ri3ru 0/1 Running 7 im 


可 以 看 到 Pod 已 经 创建 成 功 了 ， 但 Pod 的 状态 一 会 儿 是 Running， 
一 会 儿 是 ExitCode: 0，READY 列 中 始终 无 法 变 成 1， 而 且 RESTARTS 
(重启 的 数量 ) 的 数量 不 断 增 加 。 


造成 这 种 现象 是 因为 容 需 的 局 动 命令 不 能 保持 


台 运行 。 


= 


本 例 中 的 Docker 镜 像 的 启动 命令 为 : 


zkServer.sh start-background 


在 Kubernetes 根 据 RC 定 义 创建 Pod 后 启动 容器 ， 容 器 的 启动 命令 执 
行 完成 时 ， 即 认为 该 容器 的 运行 已 经 结束 ， 并 且 是 成 功 结束 
( ExitCode=0 ) 。 然 后 ， 根据 Pod 的 默认 重启 策略 定义 


iz BA 


(RestartPolicy=Always) ，RC 将 启动 这 个 容器 。 


新 的 容 右 执行 局 动 命 令 后 仍然 会 成 功 结束 ， 然 后 RC 会 再 次 重启 该 
容器 ， 进 入 一 个 无 限 循环 的 过 程 中 。 


解决 方法 为 将 Docker 镜 像 的 启动 命令 设置 为 一 个 前 台 运 行 的 命 
令 ， 例 如 : 


zkServer.sh start-foreground 


5.3.5 “寻求 帮助 


如 有 果 通 过 系统 日 志和 容 妖 日 志 都 无 法 找到 出 现 问 题 的 原因 ， 则 还 
可 以 追踪 源码 进行 分 析 ， 或 者 通过 一 些 在 线 途 径 寻 求 帮助 。 


= 


e Kubernetes 的 rf il [R] 题 参 Ii 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/User- 
FAQ ° 

。 Debugging Hy 党 见 [R] 题 参 见 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/Debugging- 
FAQ ° 


e Service Hy fit 见 [R] 题 参 见 
https://github.com/GoogleCloudPlatform/kubernetes/wiki/Services- 
FAQ ° 

e StackOverflow 网 站 关 于 Kubernetes 的 主题 参见 
http://stackoverflow.com/questions/tagged/kubernetes 或 


http://stackoverflow.com/questions/tagged/google-container-engine ° 

e IRC 频 道 ( #google-containers ) A V) 
https://botbot.me/freenode/google-containers/ ° 

e Kubernetes W (F 7| 3 Email 2 见 google- 


containers@googlegroups.com ° 


5.4 Kubernetes v1.3 开 发 中 的 狐 功 能 


本 和 对 Kubernetes v1.3 版 本 的 正在 开发 中 的 一 些 新 功能 进行 介 
绍 ， 包 括 Pet Set (用 于 管理 有 状态 的 容器 应 用 ) > init container (Pod 
中 的 初始 化 容器 ) ^ Cluster Federation (集群 联邦 管理 ) 等 内 容 。 


5.4.1 PetSet (有 状态 的 容器 ) 


在 Kubernetes 集 群 中 ， 组 成 一 个 微服 务 的 后 端 Pod 一 般 来 说 都 古 无 
状态 的 容 右 应 用 。 例 如 通过 RC 来 进行 管理 ， 只 需要 维持 Pod 的 副本 数 
量 即 可 ， 当 某 个 Pod 失 败 时 就 直接 销毁 并 重新 创建 一 个 新 的 Pod， 提 供 
能 够 水 平 扩展 的 微服 务 。 我 们 可 以 称 这 类 应 用 为 “Cattle”( 农 场 动 
物 ) ， 即 单个 实例 不 是 特别 重要 ， 可 随时 被 奉 换 。 


但 对 于 有 状态 的 应 用 来 说 ， 即 以 集群 的 方式 部 车 的 大 型 应 用 软 
件 ， 每 个 实例 都 需要 具备 唯一 的 标识 ， 并 且 各 个 实例 可 能 还 有 启动 顺 
序 的 要 求 。v1.3 版 本 新 增 了 一 种 名 为 PetSet 的 资源 对 象 ， 用 于 文 持 有 状 
态 的 容器 应 用 。 我 们 可 以 称 这 类 应 用 为 "Pet” (EW) ， 即 每 个 实例 都 
JE EXE, Sir RBA BAR 。 


Pet Set 能 够 确保 为 每 个 Pet 设置 一 个 唯一 的 号 份 标识 ， 包 括 如 下 几 
种 。 


唯一 旦 不 变 的 hostname， 并 保存 在 DNS 中 。 
唯一 的 顺序 编号 ， 用 于 确保 各 实例 的 启动 顺序 。 
为 每 个 容器 提供 永久 存储 ， 与 其 hostmmame 和 和 启动 顺序 绑 定 。 


Pet Set 能 够 用 于 许多 应 用 场景 ， 如 下 所 述 。 


数据 库 应 用 ， 例 如 MySQL 或 PostgreSQL ， 其 每 个 实例 都 需要 挂 载 
一 个 外 部 的 永久 存储 。 


。 集群 化 的 应 用 软件 ， 例 如 ZooKeeper、etcd、ElasticSearch 等 需 
集群 中 的 各 成 员 有 稳定 的 号 份 。 


下 面 的 例子 描述 了 PetSet 的 创建 和 用 法 。 


petset.yaml 
4 使 用 headless Service， 以 创建 相应 Pod 的 DNS 记录 


apiVersion: vi 

kind: Service 

metadata: 
name: nginx 
labels: 


app: nginx 


spec: 
ports: 

- port: 80 

name: web 


# *.nginx.default.svc.cluster.local 
clusterIP: None 
selector: 
app: nginx 
# PetSet 的 定义 
apiVersion: apps/vialphat 
kind: PetSet 
metadata: 


name: web 


spec: 
serviceName: "nginx" 
replicas: 2 
template: 
metadata: 
labels: 
app: nginx 
annotations: 
pod.alpha.kubernetes.io/initialized: "true" 
spec: 
terminationGracePeriodSeconds: 0 
containers: 
- name: nginx 
image: gcr.io/google containers/nginx-slim:0.8 
ports: 


- containerPort: 80 


name: web 
volumeMounts: 
- name: www 


mountPath: /usr/share/nginx/html 
volumeClaimTemplates: 
- metadata: 
name: www 
annotations: 
volume.alpha.kubernetes.io/storage-class: 
anything 


spec: 


accessModes: [ "ReadWriteOnce" ] 
resources: 
requests: 


storage: 16i 


在 PetSet 定 义 中 ， ee si eA 需 
要 系统 管理 员 预 先 创建 好 外 部 PY (Persistent Volume) ， 才 能 给 PetSet 
使 用 。 


使 用 kubectl create 命 令 创 建 该 PetSet: 


$ kubectl create -f petset.yaml 
service "nginx" created 


petset "nginx" created 


查看 创建 好 的 Pod 的 信息 : 


$ kubectl get pods 


NAME READY STATUS RESTARTS AGE 
web -0 1/1 Running 0 10m 
web-1 1/1 Running 0 10m 


可 以 看 到 每 个 Pod 的 名 称 不 再 是 通过 RC 创建 的 涡 有 一 个 UUID 的 名 
称 ， 而 是 由 “petset name” 与 一 个 序列 号 组 成 的 特定 名 称 : web-0 和 web- 
1 o 


而 Pod 名 称 也 就 是 该 Pod 的 hostmame， 即 PetSet 为 每 个 Pet 设 置 了 稳 
定 的 主机 和 名 。 


# kubectl exec web-O -- sh -c 'hostname' 
web -0 
# kubectl exec web-1 -- sh -c 'hostname' 


web-1 


同时 ， 每 个 Pod 的 网 络 身 份 也 通过 Service 的 定义 被 创建 出 来 。 根 
据 Service 的 定义 ， 该 Service 将 在 DNS 中 生成 一 条 没有 ClusterIP 的 记 
录 : 


nginx.default.svc.cluster.local 


该 Service 的 后 端 为 两 个 Pet 的 地 址 〈 可 以 看 成 是 Pet 的 服务 名 ) : 


web-0.nginx.default.svc.cluster.local 


web-1.nginx.default.svc.cluster.local 


这 两 个 Pet 的 地 址 web-0.nginx 和 web-1.nginx 将 作为 每 个 Pet 的 稳定 
网 络 吴 份 被 系统 保存 在 DNS 中 ， 供 客户 端 应 用 访问 。 


接 下 来 通过 一 个 busybox 容 事 执 行 nslookup， 验 证 Pet 的 服务 地 址 ; 


# kubectl run -i --tty --image busybox dns-test -- 
restart=Never /bin/sh 
Hit enter for command prompt 


查询 web-0.nginx: 


/ # nslookup web-0.nginx 


Server: 169.169.0.100 


Address 1: 169.169.0.100 


Name: web-0.nginx 


Address 1: 172.417.1.2 


查询 web-1.nginx: 


/ # nslookup web-1.nginx 
server: 169.169.0.100 


Address 1: 169.169.0.100 


Name: web-1.nginx 


Address 1: 172.17.1.3 


如 果 直 接 查询 Nginx 服 务 (headless service) ， 则 系统 将 返回 后 端 
两 个 Pet 的 IP 地 址 列表 : 


/ # nslookup nginx 
Server: 169.169.0.100 


Address 1: 169.169.0.100 


Name: nginx 
Address 1: 172.17.1.2 


Address 2: 172.17.1.3 


借助 于 headless service 的 功能 ， 可 以 实现 各 Pet 相互 之 间 进 行 发 现 
和 访问 e 


当前 版 本 Pet Set 的 使 用 限制 如 下 。 


。 只 有 replicas 字 段 可 以 被 更 新 ， 但 更 新 后 Pet Set 仍 然 是 按 顺序 依次 
创建 各 Pet 。 

。 删除 petset 时 ， 系 统 不 会 目 动 删除 已 经 运行 中 的 Pets vs IL 
除 。 

。 出 于 数据 安全 的 考虑 ， 在 删除 Pet 时 系统 不 会 目 动 删除 该 Pet 使 用 
的 PV 存储 。 

。 目前 不 文 持 Pet 镜像 的 滚动 升级 操作 ， 需 要 手工 完成 。 


F AB 


5.4.2 Init Container (JURK Z) 


在 很 多 应 用 场景 中 ， 应 用 在 启动 之 前 都 需要 一 些 初始 化 的 操作 ， 
例如 : 


等 待 其 他 关联 组 件 正确 运行 “例如 数据 库 或 某 个 后 台 服 务 ) ; 
基于 环境 变量 或 配置 模板 生成 配置 文件 ; 

从 远程 数据 库 获 取 本 地 所 需 配置 ， 或 者 将 目 身 注册 到 有 某 个 中 央 数 
据 库 ; 

下 载 相关 依赖 包 ， 或 者 对 系统 进行 一 些 预 配置 操作 。 


Kubernetes v1.3 版 本 引入 了 一 个 Alpha 版 本 的 新 特性 : init 
container， 用 于 在 启动 普通 容器 之 前 局 动 一 个 或 多 个 “初始 化 ”容器 ， 
完成 普通 容 右 所 需要 的 预 置 条 件 ， 如 图 5.22 所 示 。init container 与 普通 
容器 本 质 上 是 一 样 的 ， 但 它们 是 仅 运 行 一 次 就 结束 的 任务 ， 并 且 必 须 
成 功 执 行 完 成 后 ， 系 统 才能 继续 执行 下 一 个 容 右 。 根 据 Pod 的 重启 策 
W* ( RestartPolicy ) , 当 init container 执行 失败 ， 在 设置 了 
RestartPolicy=Never 时 , Pod Tí m s AM: 而 设置 
RestartPolicy=Always 时 ，Pod 将 会 被 系统 目 动 重 局 。 


Pod 
init 容器 1 
i 


init Aa 2 
l 


Application 容器 


图 5.22 init container 


在 当前 的 版 本 中 要 启用 init container 的 配置 ， 需 要 在 Pod 的 
annotation 字 段 中 设 置 pod.alpha.kubernetes.io/init-containers 来 定义 需要 


执行 的 初始 化 容器 列表 。 


下 面 ， 以 Nginx 应 用 为 例 ， 在 启动 Nginx 之 前 ， 通 过 初始 化 容 名 
busybox 为 Nginx 创 建 一 个 index.html 主 页 文件 。 


nginx-init-containers.yaml 
apiVersion: vi 
kind: Pod 
metadata: 
name: nginx 


annotations: 


pod.alpha.kubernetes.io/init-containers: '[ 


{ 
"name": "install", 
"image": "busybox", 
"command": ["wget", "-O", "/work- 


dir/index.html", "http://kubernetes.io/index.html"], 
"volumeMounts": [ 
{ 
"name": "workdir", 


"mountPath": "/work-dir" 


]' 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- containerPort: 80 
volumeMounts: 
- name: workdir 
mountPath: /usr/share/nginx/html 
dnsPolicy: Default 
volumes: 
- name: workdir 


emptyDir: {} 


创建 这 个 Pod: 


# kubectl create -f nginx-init-containers.yaml 


pod "nginx" created 


在 运行 init container 的 过 程 中 ， 查 看 Pod 的 状态 ， 可 见 Tnit 过 程 还 未 
完成 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


nginx 0/1 Init:0/1 0 im 


"Ainit container KH AT SE, SZ AE ARENginxt ss, AKA 
看 Pod 的 状态 : 


# kubectl get pods 
NAME READY STATUS RESTARTS AGE 


nginx 1/1 Running 0 7S 


查看 Pod 的 事件 ， 可 以 看 到 系统 按 顺序 运行 Pod 中 的 各 个 容器 : 


# kubectl describe pod nginx 


Name: nginx 
Namespace: default 
TET ( 略 ) 

Events: 


FirstSeen LastSeen Count From 


SubobjectPath 


Message 


4s 


scheduler } 


Scheduled 
4s 
node-1} 
Pulled 
machine 
4s 
node-1} 
Created 
4s 
node-1) 
Started 
3s 
node-1) 
Pulled 
machine 
3s 
node-1) 
Created 


2S 


Type Reason 


As 1 {default - 
Normal 
Successfully assigned nginx to k8s-node-1 
As 1 (kubelet k8s- 
spec.initContainers{install} Normal 


Container image "busybox" already present on 


As 1 {kubelet k8s- 
spec.initContainers{install} Normal 
Created container with docker id 81d3ef7ade94 
As 1 {kubelet k8s- 
spec.initContainers{install} Normal 
Started container with docker id 81d3ef7ade94 
3s 1 (kubelet k8s- 
spec.containers{nginx} Normal 


Container image "nginx" already present on 


3s 1 (kubelet k8s- 
spec.containers{nginx} Normal 
Created container with docker id 5a0bc53661f6 


2s 1 (kubelet k8s- 


node-1} spec.containers{nginx} 


Normal 
Started Started container with docker id 5a0bc53661f6 
在 init container) JA 22 1E dl ， 将 进一步 考虑 Pod 的 资源 使 用 限 


制 、 健 康 检 查 、 镜 像 更 新 等 问题 


5.4.3 ClusterFederation (集群 联邦 ) 


集群 联邦 是 管理 多 个 Kubernetes 集 群 的 集群 ， 用 于 多 个 集群 中 的 
服务 统一 管理 ， 以 及 当 一 个 集群 发 生 故 障 时 ， 能 够 将 业务 恢复 到 其 他 
集群 上 ， 如 图 5.23 所 示 。 目前 集群 联邦 只 能 在 谷歌 或 亚马逊 的 公有 云 
上 进行 配置 和 使 用 。 


5.23 ”集群 联邦 


集群 联邦 的 主要 组 件 由 Federation Control Plane (控制 平面 ) 来 完 
成 对 多 个 集群 的 管控 ， 其 核心 组 件 包括 federation-apiserver 和 federation- 
controller-manager 和 etcd， 可 以 在 已 经 存在 的 一 个 Kubernetes 集 群 上 以 
Pod 的 形式 局 动 这 些 Federation 组 件 。 


下 面 以 在 GCE 上 运行 一 个 ClusterFederation 为 例 ， 创 建 federation- 


apiserver 和 federation-controller-manager 的 命令 为 : 


$ KUBERNETES_PROVIDER=gce 
FEDERATION_DNS_PROVIDER=google-clouddns 
FEDERATION NAME-myfederation 
DNS ZONE NAME-myfederation.example 


FEDERATION PUSH REPO BASE-gcr.io/google containers 


./federation/cluster/federation-up.sh 


各 个 参数 的 侣 义 如 下 。 


。 KUBERNETES PROVIDER: 云 服务 商 。 

e FEDERATION DNS PROVIDER : 可 以 是 google-clouddns 或 者 
aws-route53。 如 果 已 经 把 KUBERNETES_PROVIDER 设 置 为 gce、 
gke 及 aws 中 的 一 个 ， 那 么 系统 会 目 动 设 置 这 一 变量 。 该 设置 项 用 
于 为 联邦 服务 提供 域名 解析 能 力 。 当 联邦 中 的 Kubernetes 集 群 上 
的 Pod 或 者 Service 发 生变 更 的 时 候 ， 会 在 DNS 记录 上 做 出 相应 的 


e FEDERATION NAME: 联邦 的 名 称 ， 这 一 名 称 也 会 反映 在 DNS 
记录 之 中 。 


e DNS ZONE NAME: DNS 记录 的 域名 。 用 户 需 要 购买 和 使 用 这 
个 域名 ， 让 FEDERATION_DNS_PROVIDER 能 够 为 这 一 域名 的 查 
询 提 供 正确 的 解析 结 


过 上 面 的 命令 会 创建 一 个 federation 命 名 空间 ， 并 创建 两 个 


M cn federation-apiserver & federation-controller-manager ° 


验证 创建 出 来 的 deployment: 


$ kubectl get deployments --namespace=federation 
NAME DESTRED CURRENT 
UP-TO-DATE AVAILABLE AGE 


federation-apiserver 1 1 
1 1 im 
federation-controller-manager 1 1 
1 1 im 


federation-up.sh 还 会 在 kubeconfig 中 创建 一 个 新 纪录 ， 用 来 和 联邦 
APIServer 进 行 通信 。 可 以 使 用 kubectlconfigview 来 查看 。 


男 外 ，federation-up.sh 创 建 的 federation-apiserver Pod 中 包含 的 etcd 
容 絮 使 用 了 PV 持久 卷 ， 用 来 提供 持久 化 数据 存储 ， 目 前 只 能 在 AWS、 
GKE 或 GCE 环 境 中 进行 创建 。 具 体 的 PV 设置 可 以 通过 修改 


federation/manifests/federation-apiserver-deployment.yaml?K FE EV, ° 


在 联邦 控制 平面 局 动 之 后 ， 束 可 以 对 现 有 的 Kubernetes 集 群 进行 
WET ° 


首先 ， 我 们 需要 创建 一 个 secret 对 象 ， 其 中 包含 了 Kubernetes 集 群 
的 kubeconfig ， 联 邦 将 会 用 这 一 内 容 和 受 管 集群 进行 通信 。 假 设 
kubeconfig 文 件 位 于 /clusterl/kubeconfig， 用 下 面 的 命令 来 创建 secret: 


$ kubectl create secret generic cluster1 -- 


namespace-federation --from-file=/cluster1/kubeconfig 


文件 名 kubeconfig 将 用 于 设置 secrete 的 key 名 称 。 


创建 好 secret 之 后 ， 束 可 以 注册 集群 了 ， 一 个 集群 对 象 的 yam] 配 置 
文件 如 下 : 


apiVersion: federation/vibetai 
kind: Cluster 
metadata: 
name: clusteri 
spec: 
serverAddressByClientCIDRs: 
- clientCIDR: «client-cidr» 
serverAddress: «apiserver-address» 
secretRef: 


name: <secret-name> 


fig Xil «client-cidr» ` <apiserver-address> € «secret-name» E£1 7 K 
En 内容 。 <secret-name> 是 前 面 刚 刚 创 建 的 secret 的 名 称 。 
serverAddressByClientCIDRs 包 含 一 系列 地 址 ， 符 合 CIDR 的 客户 端 才 能 
连接 服务 噩 的 这 一 地 址 。 我 们 可 以 设置 服务 亏 地 址 的 CIDR 
为 "0.0.0.0/0?， 这 样 所 有 的 客户 端 都 可 以 访问 。 另 外 ， 如 果 和 希望 内 部 客 
户 端 使 用 服务 器 的 clusterIP， 则 可 以 把 这 一 耳 设 置 为 serverAddress， 然 
后 设置 clientCIDR 为 集群 内 的 Pod 地 址 苑 围 。 


将 该 yaml 文 件 保存 为 /clusterl/clusteryaml， 运 行 下 面 的 命令 来 进 
行 集群 的 纳 管 : 


$ kubectl create -f /clusteri/cluster.yaml -- 


context=federation-cluster 


设 置 --context=federation-cluster $ 思 是 将 请 求 发 往 联 邦 的 


federation-apiserver ° 


$ kubectl get clusters --context=federation-cluster 
NAME STATUS VERSION AGE 


clusteri Ready 3m 


当 集 群 纳 管 之 后 ， 束 可 以 使 用 集群 联邦 的 功能 


为 了 文 持 足 集群 的 服务 发 现 机 制 ， 需 要 扩展 KubeDNS 服 务 ， 通 过 - 
-federations 参 数 设 置 集群 联邦 的 总 DNS 服务 : 


--federations=${FEDERATION_NAME}=${DNS_DOMAIN_NAME} 


可 以 通过 编辑 现 有 KubeDNS 的 RC 中 所 包含 的 Pod 模 板 来 为 Pod 加 
入 这 一 和 参数， 删除 当前 运行 的 Pod 之 后 ，RC 就 会 根据 新 的 模板 创建 带 
有 联邦 DNS 信息 的 KubeDNS 服 务 了 。 


$ kubectl get rc --namespace=kube-system 
kube-dns 的 RC 名 是 kube-dns-[id] 的 形式 ， 用 edit 井 行 编辑 : 


$ kubectl edit rc «rc-name» --namespace-kube-system 


在 弹出 的 yaml 文 件 中 加 入 --federation 参 数 ， 保 存 退 出 ， 然 后 查 诊 
并 删除 现 有 的 Pod e 


d 


$ kubectl delete pods <pod-name> --namespace-kube- 


system 


至 此 ， 集 群 联邦 设置 完成 ， 接 下 来 束 可 以 在 多 个 集群 上 部 署 应 用 
[fe 


假设 当前 已 有 4 个 集群 纳 管 进 了 集群 联邦 : 


$ kubectl get clusters --context=federation-cluster 


NAME STATUS VERSION AGE 
clusteri Ready 3m 
cluster2 Ready 3m 
cluster3 Ready 3m 
cluster4 Ready 3m 


在 这 4 个 集群 上 创建 Nginx 服 务 : 


$ kubectl --context=federation-cluster create -f 


services/nginx.yaml 


$ kubectl --context=federation-cluster describe 


services nginx 


Name: nginx 


Namespace: default 
Labels: run=nginx 
Selector: run=nginx 
Type: LoadBalancer 
IP: 
LoadBalancer Ingress: 104.197.246.190, 


130.211.57.243, 104.196.14.231, 104.199.136.89 


Port: http 80/TCP 
Endpoints: <none> 

Session Affinity: None 

No events. 


登录 其 中 一 个 集群 ， 查 看 由 federation-controller-manager 创 建 的 
Nginx 服 务 : 


$ kubectl --context=cluster1 get svc nginx 
NAME CLUSTER- IP EXTERNAL - IP PORT(S) 
AGE 


nginx 10.63.250.98 104.199.136.89 80/TCP 9m 


可 以 看 到 集群 联邦 通过 在 每 个 集群 上 创建 一 个 同名 的 服务 ， 但 此 
时 由 于 每 个 集群 的 Service 后 端 还 没有 运行 任何 Pod， 所 以 这 些 联邦 服 
务 还 无 法 正常 工作 。 


接 下 来 通过 在 每 个 集群 上 运行 Pod 来 支撑 Service: 


kubectl --context=cluster1 run nginx -- 
image=nginx:1.11.1-alpine --port=80 

kubectl --context=cluster2 run nginx -- 
image=nginx:1.11.1-alpine --port=80 

kubectl --context=cluster3 run nginx -- 
image=nginx:1.11.1-alpine --port=80 


kubectl --context=cluster4 run nginx -- 


e 9 e 0€ pb fF BB A 


image-nginx:1.11.1-alpine --port-80 


当 这 些 Pod 成 功 运行 后 ，Service 将 被 集群 联邦 设置 为 正常 状态 ， 
然后 集群 联邦 将 会 配置 相应 的 公共 DNS 记录 。 假 设 使 用 的 是 Google 
Cloud DNS， 并 且 DNS 域 名 为 example.com， 则 可 以 看 到 每 个 集群 上 的 
Nginx 服 务 都 被 设置 好 了 一 个 DNS 和 名， 可 供 其 他 应 用 访问 时 使 用 : 


$ gcloud dns managed-zones describe example-dot-com 
creationTime: '2016-06-26T18:18:39.229Z' 
description: Example domain for Kubernetes Cluster 

Federation 

dnsName: example.com. 

id: '3229332181334243121' 

kind: dns#managedZone 

name: example-dot-com 

nameServers: 

- ns-cloud-ai1.googledomains.com. 

- ns-cloud-a2.googledomains.com. 

- ns-cloud-a3.googledomains.com. 


- ns-cloud-a4.googledomains.com. 


$ gcloud dns record-sets list --zone example-dot-com 


NAME 

TYPE TTL DATA 
example.com. 
NS 21600 ns-cloud-e1.googledomains.com., ns-cloud- 


e2.googledomains.com. 
example.com. 
SOA 21600 ns-cloud-e1.googledomains.com. cloud-dns- 
hostmaster.google.com. 1 21600 3600 1209600 300 
nginx.mynamespace.myfederation.svc.example.com. 
A 180 104. XXX . XXX .XXX, | 130. XXX.XX.XXX, 
104.XXX.XX.XXX, 104.XXX.XXX.XX 


nginx.mynamespace.myfederation.svc.clusteri.example.com. 


A 180 104 . XXX . XXX . XXX 


nginx.mynamespace.myfederation.svc.cluster2.example.com. 
A 180 104.XXX.XXX.XXX, 104.XXX. XXX. XXX, 


104 . XXX . XXX . XXX 


nginx.mynamespace.myfederation.svc.cluster3.example.com. 


A 180 130 . XXX. XX. XXX 


nginx.mynamespace.myfederation.svc.cluster4.example.com. 


A 180 130.XXX.XX.XXX, 130.XXX.XX.XXX 


nginx.mynamespace.myfederation.svc.cluster4.example.com. 
CNAME 180 


nginx .mynamespace.myfederation.svc.example.com. 
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6.1 Kubernetes 源 人 码 结构 和 编译 步骤 


Kubernetes 的 源码 现在 托管 在 GitHub 上,， 地 址 为 
https://github.com/googlecloudplatform/kubernetes ° 


编译 脚本 存放 在 build 子 目录 下 ， 在 Linux 环 境 (可 以 是 虚拟 机 ) 中 
执行 如 下 命令 即 可 完成 代码 的 编译 过 程 : 


git clone 
https://github.com/GoogleCloudPlatform/kubernetes.git 
cd kubernetes/build 


./release.sh 


制作 release 的 过 程 其 实 有 不 少 有 意思 的 事情 发 生 ， 包 括 局 动 
Docker 容 器 来 安装 Go 语言 环境 、etcd 等 ， 读 者 若 有 兴趣 则 可 以 查看 
release.sh 肢 本。 另外， 如 果 编 译 环 境 是 通过 HTTP 代 理 上 网 的 ， 则 需要 
设置 好 Git 与 Docker 相关 的 HITP 人 代理 参 数 ， 同 时 在 文件 
kubernetes/build/build-image/Dockerfile 中 增加 如 下 HTTP 代 理 参数 。 


e ENV http proxy-http:/username : password@proxyaddr 
proxyport ° 

e ENV https proxy-http:;/username : password@proxyaddr 
proxyport ? 


在 编译 过 程 中 产生 的 与 Docker 相 关 的 docker image ` dockerfile/? Fri 
H 好 的 二 进 制 文件 包 ， 则 存放 在 kubermetes/_output 目 隶 下 ， 这 个 目 隶 
总 共有 4 个 子 目 录 : dockerized ^ images ^ release-stage ` release-tars, 3X 
们 关心 后 两 个 日 录 ， 其 中 release-stage 目 录 下 存放 的 是 支持 linux-amd64 
架构 的 Server 端 的 二 进 制 可 执行 文件 ( 放 在 server 子 目录 下 ) ， 以 及 文 
持 不 同 平 台 的 Client 端 的 二 进 制 可 执行 文件 ( 放 在 dient 子 目录 下 ) ， 
release-tars 则 存放 的 是 release-stage 目 录 下 各 级 子 目录 的 压缩 包 ， 与 从 
官方 网 站 下 载 的 完全 一 样 。 


考虑 到 学 习 和 调试 Kubernetes 代 码 的 便利 性 ， 我 们 接 下 来 介绍 如 
何在 Windows 的 LiteIDE 开 发 环境 中 完成 Kubemetes 代 码 的 编译 和 调 
试 。 本 文 假设 Windows 上 的 GO 运行 时 框架 和 LiteIDE 开 发 环境 已 经 建立 
tE Jt 通 过 gt doe 命令 已 经 将 
https://github.com/GoogleCloudPlatform/kubernetes.git F £X 2!) AS H C : 
\kubernetes 目 录 中 。 通 过 分 析 Kubernetes 的 目录 结构 ， 我 们 发 现 
Kubemetes 的 源码 都 在 pkg 子 目录 下 。 接 下 来 建立 k8s 工 程 目 录 ， 目 录 位 
置 为 C: \projectgo\k8s， 并 在 里 面 建立 src、pkg 两 个 子 目录 ， 人 然后 把 
C: \kubernetes\Godeps\、 workspace\src 全 部 转移 到 C: \project\go\k8s\src 
目录 下 ， 因 为 这 里 是 Kubemetes 源 码 的 所 有 依赖 包 ， 所 以 如 果 手 动 一 
个 一 个 地 下 载 ， 则 娩 怕 以 国内 的 网 速 一 天 也 搞 不 是。 转移 完 成 后 ， 
C: \project\go\k8s\src 的 目录 结构 包括 如 下 内 容 : 


C:\project\go\k8s\src>dir 


2015-07-14 11:56 <DIR> bitbucket.org 
2015-07-14 11:56 <DIR> code.google.com 
2015-07-17 12:30 <DIR> github.com 
2015-07-14 11:56 <DIR> golang.org 
2015-07-14 11:56 <DIR> google.golang.org 
2015-07-14 11:56 <DIR> gopkg.in 
2015-07-14 11:56 <DIR> speter.net 


fe M 3X JÉ C : \kubernetes 的 整个 目录 移动 到 C 
\project\go\k8s\src\github.com\GoogleCloudPlatform\ F , 7; Kubernetes 
HJ is Ag 包 的 xt 整 4 字 
为 “github.com/GoogleCloudPlatform/kubernetes/pkg”。 上述 工作 完成 以 
后 ， 所 有 的 源码 都 在 C: \project\go\k8s\src 目 未 下 了 ， 我 们 用 LiteIDE 打 
JFC: \project\go\k8s， 单 击 采 单 “查看 ”> “管理 Gopath” 一 添加 目 孙 “C: 
MrojectgoW8s" , 然 后 可 以 进入 H X 
github.com/GoogleCloudPlatform/kubernetes/pkg 下 ， 逐一 编译 每 个 
package 目 孙 了 ， 如 图 6.1 所 示 。 


Åe TE LitelDE ee 7 = NEN 
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| bitbucket.org/berti x V kubernetes/pkg/client/unversioned/auth 
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| [D 1: EventLog | 2: Build Output | 3: Search Result 4: HTML Preview 5: Debug Output 6; Oracle 7: Golang Doc Search 


图 6.1 LiteIDE 编 译 Kubernetes 的 package 


在 每 个 package 都 编译 完成 以 后 ， 我 们 可 以 竹 试 局 动 kube-scheduler 
进 程 在 LiteIDE 里 jJ 开 
github.com/GoogleCloudPlatform/kubernetes/pkg/plugin/cmd/kube- 
scheduler/schedulergo, ， 并 且 按 快捷 键 Ctl+R ， 你 会 尺 奇 地 发 现 这 个 
Kubernetes HR 55 am Yim t fE Fa 4A th BE TE Windows FiS 47 ER 9 A Re 
LiteIDE 输 出 的 控制 台 日 志 : 


c:/go/bin/go.exe build -i 
[C:/project/go/k8s/src/github.com/GoogleCloudPlatform/kuber 
netes/plugin/cmd/kube-scheduler] 

成 功 : 进程 退出 代码 0 ° 


C:/project/go/k8s/src/github.com/GoogleCloudPlatform/kubern 


etes/plugin/cmd/kube-scheduler/kube-scheduler.exe 
[C:/project/go/k8s/src/github.com/GoogleCloudPlatform/kuber 
netes/plugin/cmd/kube-scheduler] 

WO717 16:05:26.742413 11344 server.go:83] Neither -- 
kubeconfig nor --master was specified. Using default API 
client. This might not work. 

E0717 16:05:27.747413 11344 reflector.go:136] Failed 
to list *api.Node: Get http://localhost:8080/api/vi/nodes 
fieldSelector=spec.unschedulable%3Dfalse: dial tcp 
127.0.0.1:8080: ConnectEx tcp: No connection could be made 
because the target machine actively refused it. 

E0717 16:05:27.748413 11344 reflector.go:136] Failed 
to list ‘*api.Pod: Get M http://localhost:8080/api/v1/pods 
fieldSelector=spec.nodeName%21%3D: dial tcp 127.0.0.1:8080: 
ConnectEx tcp: No connection could be made because the 


target machine actively refused it. 


在 Kubernetes 的 源码 里 包括 不 少 单元 测试 ， 你 可 以 在 LiteIDE 里 运 
行 通过 ， 但 有 部 分 测试 代码 目前 在 Windows 上 无 法 通过 ， 毕 苋 
Kubermnetes 是 为 Linux 打 造 的 。 拉 下 来 我 们 分 析 下 Kubernetes 源 码 的 整体 
结构 ，Kubernetes 的 源码 总 体 分 为 pkg、cmd、plugin、test 等 顶级 
package， 其 中 pkg 为 Kubernetes 的 主体 代码 ，cmd 为 Kubernetes 所 有 后 
台 进 程 的 代码 (如 kube-apiserver 进 程 、kube-controller-manager 进 程 、 
kube-proxy if #@ ` kubeletit #2“) ，plugin 则 包括 一 些 插件 及 kuber- 
scheduler 的 代码 ，test 包 是 Kubernetes 的 一 些 测 试 代 码 。 


从 总 体 来 看 ，Kubernetes 1.0 的 当前 包 结 构 还 是 有 点 乱 ， 开 源 团 队 
还 在 继续 优化 中 ， 可 以 从 源码 的 TODO 注 释 中 看 出 这 一 点 。 表 6.1 给 出 
了 Kubermetes 当 前 主要 package 的 源码 分 析 结 果 。 


表 6.1 Kubermetes 主 要 package 的 源码 分 析 结 果 


package 模块 用 途 
admission 权限 控制 框架 ， 采 用 了 责任 链 模 式 、 插 件 机 制 
api Kubernetes 所 提供 的 Rest API 接口 的 相关 类 ， 例 如 接口 数据 结构 相关 的 MetaData 结构 、 
Volume 结构 、Pod 结构 、Service 结构 等 ， 以 及 数据 格式 验证 转换 工具 类 等 ， 由 于 API 是 分 


版 本 的 ， 所 以 这 里 是 每 个 版 本 一 个 子 Package， 例 如 vlbeta、v1 及 latest 


-个 基础 性 框架 ， 用 于 Kubernetes 的 各 种 Rest API 的 实现 ， 在 


apiserver 实现 了 HTTP Rest 服务 的 
apiserver 包 里 也 实现 了 HTTP Proxy， 用 于 转发 请 求 〈 到 其 他 组 件 ， 比 如 Minion 节点 上 ) 


3A 认证 模块 ， 包 括 用户 认 证 、 鉴 权 的 相关 组 件 


auth 


续 表 
是 Kubemetes 中 公用 的 客户 端 部 分 的 相关 代码 ， 实 现 协 议 为 HTTPRest, 用 于 提供 一 个 具 
体 的 操作 ， 例 如 对 Pod, Service 等 的 增删 改 查 ， 这 个 模块 也 定义 了 kubeletClient， 同 时 为 
了 高 效 地 进行 对 象 查询 ， 此 模块 也 实现 了 一 个 带 缓存 功能 的 存储 接口 Store 
定义 了 云 服 提 供 商 运行 Kubernetes 所 需 的 接口 , 包括 TCPLoadBalancer 的 获取 和 创建 ; 获 | 中 
取 当前 环境 中 的 节点 列表 (节点 是 一 个 云 主 机 ) 和 节点 的 具体 信息 ， 获 取 Zone 信息 : 获 
取 和 管理 路 由 的 接口 等 ， 默认 实现 了 AWS、GCE、Mesos、OQpenStack 、RackSpace 等 云 服 
务 供应 商 的 接口 
m ik RET VENE MR OME, PANNE. eS. EAHA 
执行 ， 同 时 实现 了 Kubernetes 的 ReplicationController if] FL (£748 


Kubernetes 的 命令 行 工具 kubectl 的 代码 模块 ， 包 括 创 建 Pod、 服 务 、Pod 扩容 、Pod RH) 
升级 等 各 种 命令 的 具体 实现 代码 


cloudprovider 

Kubernetes 的 kubelet 的 代码 模块 ， 是 Kubernetes 的 核心 模块 之 一 ， 定 义 了 Pod 容器 的 接 

口 ， 提 供 了 Docker 与 Rit 两 种 容器 实现 类 ， 完 成 了 容器 及 Pod 的 创建 ， 以 及 容器 状态 的 

Wie. MER. HURTS D 

Kubemetes 的 Master i ARUBA. fist NodeRegistry, PodRezistry, ServiceRegistry. 

EndpointRegistry 等 组 件 ， 并 且 启动 Kabemetes 自身 的 相关 服务 ， 服 务 的 ClusterIP 地 址 分 

配 及 服务 的 NodePort 端口 分 配 ， 也 是 在 这 里 完成 的 

me Kubernetes 的 服务 代理 和 负载 均衡 相关 功能 的 模块 代码 ,目前 实现 了 round-robin 的 负载 均 

wi Mik 

registry Kubernetes 的 NodeRezistry. PodeRegistry. ReplicationControllerRegistry, ServiceRegistry. 

EndpointRegistry, PersistentVolumeRegisty 等 注册 表 服 务 的 接口 及 对 应 Rest 服务 的 相关 代 
码 

为 了 让 多 个 API 版 本 共存 ， 需 要 采用 一 些 设计 来 完成 不 同 API 版 本 的 数据 结构 的 转换 ，API 
中 数据 对 象 的 Encode Decode 逐 辑 也 最 好 集中 化 ，Runtime 包 就 是 为 了 这 个 目的 而 设计 的 

i 实现 了 Kubemetes 的 各 种 Volume 类 型 ， 分 别 对 应 亚马逊 ESB 存储、 谷歌 GCE 的 存储 、 

Linux Host 目录 存 鳍 、GlusterFS 存储 、iSCSI 7# fifi. NFS 存储 、RBD 存储 等 ，volume 包 
同时 实现 了 Kubemetes 容器 的 Volume NHE. MEDIE 
包括 了 Kubemetes 所 有 后 台 进 程 的 代码 如 kube-apiserver 进程 、kube-controller-manager 
进程 、kube-proxy 进程 、kubelet 进程 等 )， 而 这 些 进程 具体 的 业务 逻辑 代码 则 都 在 pkg 中 
实现 了 


子 包 cmd/kuber-scheduler 实现 了 Schedule Server 的 框架 ， 用 于 执行 具体 的 Scheduler 的 调 | 中 
度 ,pkg/admission 子 包 则 实现 了 Admission 权限 框架 的 一 些 默认 实现 类 ,例如 ahwaysAdmit、 
alwaysDeny 等 ; pkg/auth 子 包 实 现 了 权限 认证 框架 (auth 包 的 ) 里 定义 的 认证 接口 类 ， 例 


如 HTTP BasicAuth. X509 证 书 认证 : pke/scheduler 子 包 则 定义 了 一 些 具体 的 Pod 调度 器 
( Scheduler) 


6.2 kube-apiserverZt fey fid 2j T 


Kubernetes APIServer Æ 由 kube-apiserver 进 程 实现 的 ， 它 运行 在 
Kubernetes 的 管理 节点 Master 上 并 对 外 提供 Kubernetes Restful API 
服务 ， 它 提供 的 主要 是 与 集群 管理 相关 的 API 服 务 ， 例 如 校 验 pod、 
service ^ replication controller 的 配置 并 存储 到 后 端的 etcd Server 上 。 下 
面 我 们 分 别 对 其 局 动 过 程 、 关 键 代 码 分 析 及 设计 总 结 等 进行 深入 讲 
fg o 


6.2.1 进程 局 动 过 程 


kube-apiserver 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube- 


apiserver/apiserver.go 


ALHmain () 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 


rand.Seed(time.Now().UTC().UnixNano()) 


S := app.NewAPIServer() 
s.AddFlags(pflag.CommandLine) 


util.InitFlags() 
util.InitLogs() 


defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err :- s.Run(pflag.CommandLine.Args()); err != 


nil { 
fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 


上 述 代 码 的 核心 为 下 面 三 行 ， 创 建 一 个 APIServer 结 构 体 并 将 命令 
行 局 动 参数 传 入 ， 最 后 局 动 监 昕 : 


S := app.NewAPIServer() 
s.AddFlags(pflag.CommandLine) 


s.Run(pflag.CommandLine.Args()) 


我 们 移 来 看 看 都 有 哪些 常用 的 命令 行 参 数 被 传递 给 了 APIServer 对 
象 ， 下 面 是 运行 在 MasterT 点 的 kube-apiserver 进 程 的 命令 行 信息 : 


/usr/bin/kube-apiserver  --logtostderr-true  -- 
etcd_servers=http://127.0.0.1:4001 --address=0.0.0.0 -- 
port=8080 --kubelet_port=10250 --allow privileged-false -- 


service-cluster-ip-range=10.254.0.0/16 


可 以 看 到 关键 的 几 个 参数 有 etcd_servers 的 地 址 、APIServer 绑 定 和 
监听 的 本 地 地 址 、kubelet 的 运行 端口 及 Kubernetes 服 务 的 clusterIP 地 
址 。 


下 面 是 app.NewAPIServer () 的 代码 ， 我 们 看 到 这 里 的 控制 还 是 
很 全 面 的 ， 包 括 安 全 控制 (CertDirectory ` HTTPS 默 认 启 动 ) ^ BUR 
控制 ( AuthorizationMode 、AdmissionControl ) 、 服 务 限 流 控 制 

(APIRate、APIBurst) 等 ， 这 些 逻 辑 说 明了 APlIServer 是 按照 企业 级 平 
台 的 标准 所 设计 和 实现 的 。 


func NewAPIServer() *APIServer { 
s := APIServer{ 


InsecurePort: 8080, 


InsecureBindAddress: 


util.IP(net.ParseIP("127.0.0.1")), 


BindAddress: 
util.IP(net.ParseIP("0.0.0.0")), 
SecurePort: 6443, 
APIRate: 10.0, 
APIBurst: 200, 
APIPrefix: "/api", 
EventTTL: 1 * time.Hour, 
AuthorizationMode: "AlwaysAllow", 
AdmissionControl: "AlwaysAdmit", 
EtcdPathPrefix: 


master .DefaultEtcdPathPrefix, 
EnableLogsSupport: true, 
MasterServiceNamespace: api.NamespaceDefault, 
ClusterName: "kubernetes", 


CertDirectory: "/var/run/kubernetes", 


RuntimeConfig: make(util.ConfigurationMap), 
KubeletConfig: client.KubeletConfig{ 
Port: ports.KubeletPort, 
EnableHttps: true, 


HTTPTimeout: time.Duration(5) 


* 


time.Second, 


ty 


return &s 


创建 了 APIServer 结 构 体 实例 后 ，apiservergo 将 此 实例 传 入 子 包 
app/server.go 的 func (s*APIServer) Run (_[Jstring) 方法 里 ， 最 终 绑 定 
本 地 端口 并 创建 一 个 HTTP Server 与 一 个 HITPS Server， 从 而 完成 整个 
进程 的 启动 过 程 。 


Run 方 法 的 代码 有 很 多 ， 这 里 就 不 再 列 出 源码 ， 对 该 方法 的 源码 
解读 如 下 。 


(1) 调用 verifyClusterIPFlags 方 法 ， 验 证 ClusterIP 参 数 是 否 已 设 
置 及 是 否 有 效 。 


(2) 验证 etcd-servers 的 参数 是 否 已 设置 。 


3) 如 果 初 始 化 CloudProvider， 且 没有 CloudProvider 的 参数 ， 则 


(4) 根据 KubeletConfig 的 配置 参数 ， 调 用 pkg/Client/kubeclient.go 

中 的 方法 NewKubeletClient () 创建 一 个 kubelet Client 对 象 ， 这 其 实 是 

一 个 HITPKubeletClient 实例 ， 目 前 只 用 于 kubelet 的 健康 检 碍 
(KubeletHealthChecker) 。 


(5) 判断 哪些 API Version 需 要 关闭 ， 目 前 在 1.0 代 码 中 默认 关闭 
了 vlbeta3 的 API 版 本 。 


(6) 创建 一 个 Kubernetes 的 RestClient 对 象 ， 具 体 的 代码 在 
pkg/client/helper.go 的 TransportFor () 方法 里 完成 ， 通 过 它 完成 Pod ^ 
Replication Controller 及 Kubernetes Service 等 对 象 的 CRUD 操 作 。 


(7) 创建 用 于 访问 etcd Server 的 客户 端 ， 具 体 代码 在 newEtcd () 
方法 里 实现 ， 从 代码 调用 中 可 以 看 出 ，Kubermetes 采 用 的 是 
github.comy/coreos/go-etcd/client.go 这 个 客户 端 实现 。 


(8) 建立 鉴 权 (Authenticator) 、 授 权 (Authorizer) 、 服 务 许可 
框架 和 插件 (AdmissionControl) 的 相关 代码 逻辑 。 


(9) 获取 和 设置 APIServer 的 ExternalHost 的 名 称 ， 如 果 没 有 提供 
ExternalHost 参 数 ， 且 Kubernetes 运 行 在 谷歌 的 GCE 云 平台 上 ， 则 和 莹 试 
通过 CloudProvider 接 口 获取 本 机 点 的 外 部 卫 地 址 9 


(10) 如 果 运 行 在 云 平台 中 ， 则 安装 本 机 的 SSH Key 到 Kubernetes 
集群 中 的 所 有 虚拟 机 上 。 


(11) 用 APIServer 的 数据 及 上 述 过 程 中 创建 的 一 些 对 象 
(KubeletClient ` etcdClient ` authenticator 、admissionController 等 ) 作 
为 参数， 构造 Kubernetes Master 的 Config 结 构 
(pkg/master/master.go) ， 以 此 生成 一 个 Master 实 例 ， 具 体 代 码 在 
master.go 中 的 New (c*Config) 方法 里 。 


(12) 用 上 述 创建 的 Master 实 例 ， 分 别 创建 HTTP Server 及 安全 的 
HTTPS Server 来 开始 监听 客户 端的 请 求 ， 至 此 整个 进程 启动 完毕 。 


6.2.2 ”关键 代码 分 析 


在 6.2.1 世 里 对 kube-apiserverj 进 程 的 启动 过 程 进行 了 详细 分 析 ， 我 
们 发 现 Kubernetes API Service 的 关键 代码 天 隐藏 在 pkg/masterymaster.go 
里 ，APIServer 这 个 结构 体 只 不 过 是 一 个 参数 传递 通道 而 已 ， 它 的 数据 
最 终 传 给 了 pkg/master/master.go 里 的 Master 结 构 体 ， 下 面 是 它 的 完整 定 
Xa 


// Master contains state for a Kubernetes cluster 
master/api server. 
type Master struct ( 
// "Inputs", Copied from Config 
serviceClusterIPRange *net.IPNet 


serviceNodePortRange util.PortRange 


cacheTimeout time.Duration 
minRequestTimeout time.Duration 

mux apiserver.Mux 
muxHelper *apiserver.MuxHelper 
handlerContainer *restful.Container 
rootWebService *restful.WebService 


enableCoreControllers bool 
enableLogsSupport bool 


enableUISupport bool 


enableSwaggerSupport bool 
enableProfiling bool 
apiPrefix string 


corsAllowedOriginList 


util.StringList 


authenticator authenticator .Request 
authorizer authorizer.Authorizer 
admissionControl admission.Interface 
masterCount int 

vibeta3 bool 

vi bool 


requestContextMapper 


api.RequestContextMapper 


// External host is the name that should be used 


externalHost string 


// clusterIP is the 


within the cluster. 


clusterIP 
publicReadwritePort int 
serviceReadwriteIP 
serviceReadwritePort int 


masterServices 


net. 


net. 


in external (public internet) URLs for this master 


IP address of the master 


IP 


IP 


*util.Runner 


// storage contains the RESTful endpoints exposed 


by this master 


storage map[string]rest.Storage 


// registries are internal client APIs for 


accessing the storage layer 
// TODO: define the internal typed interface ina 
way that clients can 


// also be replaced 


nodeRegistry minion.Registry 
namespaceRegistry namespace.Registry 
serviceRegistry service.Registry 
endpointRegistry endpoint .Registry 


serviceClusterIPAllocator service.RangeRegistry 
serviceNodePortAllocator service.RangeRegistry 
// "Outputs" 

Handler http.Handler 


InsecureHandler http.Handler 


// Used for secure proxy 


dialer apiserver.ProxyDialerFunc 
tunnels *util.SSHTunnelList 
tunnelsLock sync.Mutex 


installSSHKey InstallSSHKey 
lastSync int64 // Seconds since Epoch 
lastSyncMetric prometheus.GaugeFunc 


clock util.Clock 


WY 


在 这 段 代 码 里 ， ER T ZB AAP we a SIL tae 
的 重要 变量 ， 接 下 来 我 们 逐一 对 其 进行 分 析 讲 解 。 


首先 是 类 型 为 apiserver.Mux (Æ BH X: ff pkg/apiserver/apiserver.go) 
的 mux 变 量 ， 下 面 是 对 它 的 定义 : 


// mux is an object that can register http handlers. 
type Mux interface { 
Handle(pattern string, handler http.Handler ) 
HandleFunc(pattern string, handler 
func(http.Responsewriter, *http.Request) ) 
} 


如 有 果 你 熟悉 Socket 编 程 ， 特 别 使 用 过 或 者 研究 过 HTTP Rest 的 一 些 
框架 ， 那 么 对 于 这 个 Mux 接 口 束 再 熟悉 不 过 了 ， 它 是 一 个 HTTP 的 多 分 
$$ (Multiplexer) ， 其 实 它 也 是 Golang HTTP 基 础 包 里 的 http.ServeMux 
的 一 个 接口 子 集 ， 用 于 派发 (Dispatch) 某 个 Request 路 径 (这 里 用 
pattern 变 量 表示 ) 到 对 应 的 http.Handler 进 行 处 理 。 实 际 上 在 master.go 
代码 中 是 生成 一 个 http.ServeMux 对 象 并 赋值 给 apiserver.Mux 变 量 ， 在 
代码 中 还 有 强制 类 型 转换 的 语句 。 从 上 壕 分 析 来 看 ，apiserver.Mux 的 
引入 是 设计 的 一 个 败笔 ， 并 没有 增加 什么 价值 ， 反 而 增加 了 理解 代码 
的 难度 。 此 外 ， 为 了 更 好 地 实现 Rest 服 务 ，Kubernetes 在 这 里 引入 了 一 
个 第 三 方 的 REST 框 架 : github.com/emicklei/go-restful ° 


go-restful 在 GitHub 上 有 36 个 页 献 者 ， 采 用 了 “路 由 ”映射 的 设计 思 
想 ， 并 且 在 API 设 计 中 使 用 了 流行 的 Fluent Style 风 格 ， 使 用 起 来 醋 畅 淋 
注 ， 也 难怪 Kubernetes 选 择 了 它 。 下 面 是 go-restful 的 优良 特性 。 


e Ruby on Rails 风 格 的 Rest 路 Hi BR 5 ， 例 
"ll|/people/fperson id)/groups/fgroup. id) ° 
。 大 大 简化 了 Rest API 的 开发 工作 。 


底层 实现 采用 Golang 的 HTTP 协 议 栈 ， 几 乎 没有 限制 。 
拥有 完整 的 单元 包 代码 ， 很 容易 开发 一 个 可 测试 的 Rest API ° 
Google AppEngine ready ° 


go-restful 框 架 中 的 核心 对 象 如 下 。 


restful.Container : 代表 一 个 HITP Rest ik 4 a, #74 — 4 

restful.WebService 对 象 和 一 个 http.ServeMux 对象， 使 用 

RouteSelector 进 行 请 求 派发 。 

restful.WebService: 表示 一 个 Rest 服 务 ， 由 多 个 Rest 路 由 
(restful.Route) 组 成 ， 这 一 组 Rest 路 由 共享 同一 个 Root Path 。 

restful.Route: 表示 一 个 Rest 路 由 ，Rest 路 由 主要 由 Rest Path ^ 

HTTP Method、 输 入 输出 类 型 (HTML/JSON) 及 对 应 的 回调 函数 

restful.RouteFunction 组 成 。 

restful.RouteFunction: 一 个 用 于 处 理 具 体 的 REST 调 用 的 函数 接口 

定义 ， 具 体 定 义 为 type RouteFunction func ( *Request , 


*Response) 。 


Master 结 构 体 里 包含 了 对 restful.Container 与 restful.WebService 这 两 


个 go-restful 核 心 对 象 的 引用 ， 在 接 下 来 的 Master 对 象 的 构造 方法 中 
(对 应 代码 为 master.go 的 func New (c*Config) *Master) 被 初始 化 。 
那么 ， 问 题 又 来 了 ，Kubernetes 的 这 么 一 堆 Rest API 又 是 在 哪里 定义 


的 ， 


是 如 何 被 绑 定 到 restful.Route 里 的 呢 ? 


要 理解 这 个 问题 ， 我 们 要 首先 弄 清 楚 Master 结 构 体 中 的 变量 : 


storage map[string]rest.Storage 


storage 2 & z= — ^ Map, Key Rest APIA path, Value 为 
rest.Storage 接 口 ， 此 接口 是 一 个 通用 的 符合 Restful 要 求 的 资源 存储 服 
务 接口 ， 每 个 服务 接口 负责 处 理 一 类 (Kind) Kubernetes Rest API 中 的 
数据 对 象 资源 数据 ， 只 有 一 个 接口 方法 : New () , New O0 Ù 
法 返回 该 Storage 服 务 所 能 识别 和 管理 的 某 种 具体 的 资源 数据 的 一 个 空 
实例 。 


type Storage interface { 


New() runtime.Object 


在 运行 期 间 ，Kubernetes API Runtime 运 行 时 框架 会 把 New () 77 
法 返回 的 空 对 象 的 指针 传 入 Codec.DecodeInto ( []byte , 
runtime.Object) 方法 中 ， 从 而 完成 HTTP Rest 请 求 中 的 Byte 数 组 反 序列 
化 逻辑 。Kubernetes API Server 中 所 有 对 外 提供 服务 的 Restful 资 源 都 实 
现 了 此 接口 ， 这些 资 源 包 括 pods ^ bindings ^ podTemplates ^ 
replicationControllers ` services 等， 完整 的 列表 就 在 master.go HY func 

(m*Master) init (c*Config) 中 ， 下 面 是 相关 代码 片段 (截取 部 分 代 
fi) 。 


m.storage = map[string]rest.Storage{ 


"pods": podStorage.Pod, 
"pods/status": podStorage.Status, 
"pods/1log": podStorage.Log, 
"pods/exec": podStorage.Exec, 


"pods/portforward": podStorage.PortForward, 


"pods/proxy" : podStorage.Proxy, 


"pods/binding": podStorage.Binding, 


"bindings": podStorage.Binding, 
"podTemplates": podTemplateStorage, 


"replicationControllers": controllerStorage, 
"services": 
service.NewStorage(m.serviceRegistry, m.nodeRegistry, 
m.endpointRegistry, serviceClusterIPAllocator, 
serviceNodePortAllocator, c.ClusterName), 
"endpoints": endpointsStorage, 


"minions": nodeStorage, 


看 到 上 面 这 段 代 码 ， 你 在 潜意识 里 已 经 明白 ， 这 其 实 束 是 似 曾 相 
识 的 Kubernetes Rest API 列 表 ，storage 这 个 Map 的 Key 就 是 Rest API 的 访 
问 路 径 ，Value 却 不 是 之 前 说 好 的 restful.Route。 聪 明 的 你 一 定 想到 了 答 
R: 必然 存在 一 个 “转换 适 配 * 的 方法 来 实现 上 壕 转 换 ! 这 段 不 难 理解 
但 源码 超 长 的 方法 就 在 pkg/apiservervapi_installergo 的 下 述 方 法 里 : 


func (a *APIInstaller) registerResourceHandlers(path 
string, storage  rest.Storage, ws *restful.WebService, 


proxyHandler http.Handler ) 


E walt 7; TE dE — ^ path Xf JY AY rest.Storage 转换 成 一 系列 的 
restful.Route 并 添加 到 指针 restful.WebService 中 。 这 个 函数 的 代码 之 所 
以 很 长 ， 是 因为 有 各 种 情况 要 考虑 ， 比 如 pods/portforward 这 种 路 径 要 
处 理 child4， 还 要 判断 每 种 的 Storage 资 源 类 型 所 文 持 的 操作 类 型 ， 比 如 


fe f x FF create ^ delete ^ update K 7 di x FFlist ^ watch ^ patcher#E/F 
等 ， 对 各 种 情况 都 考虑 以 后 ， 这 个 函数 的 代码 量 已 接近 500 行 ! 估计 
Kubermetes 这 段 代 码 的 作者 也 不 大 好 意思 ， 于 是 外 面 封 帮 了 简单 函 
数 : func ( a*APIInstaler ) Install , 内 部 循环 调用 
registerResourceHandlers， 返 回 最 终 的 restful.WebService 对 象 ， 此 方法 
的 主要 代码 如 下 : 


// Installs handlers for API resources. 
func (a *APIInstaller ) Install() (ws 
*restful.WebService, errors []error) { 
// Register the paths in a deterministic (sorted) 
order to get a deterministic swagger spec. 
paths :- make([]string, len(a.group.Storage)) 
var i int - O 
for path := range a.group.Storage { 
paths[i] = path 
i++ 
} 
sort.Strings(paths) 
for _, path := range paths { 
if err := a.registerResourceHandlers(path, 
a.group.Storage[path], ws, proxyHandler); err != nil { 


errors = append(errors, err) 


j 


return ws, errors 


为 了 区 分 API 的 版 本 ， 在 apiservergo 里 定义 了 一 个 结构 体 : 
APIGroupVersion。 以 下 是 其 代码 : 


type APIGroupVersion struct { 
Storage map[string]rest.Storage 
Root string 
Version string 
// ServerVersion controls the Kubernetes 
APIVersion used for common objects in the apiserver 
// schema like api.Status, api.DeleteOptions, and 
api.ListOptions. Other implementors may 
// define a version "vibetai" but want to use the 
Kubernetes "vibeta3" internal objects. If 
// empty, defaults to Version. 


ServerVersion string 
Mapper meta.RESTMapper 


Codec runtime.Codec 

Typer runtime.ObjectTyper 
Creater runtime.ObjectCreater 
Convertor runtime.ObjectConvertor 


Linker runtime.SelfLinker 


Admit admission. Interface 


Context api.RequestContextMapper 


ProxyDialerFn ProxyDialerFunc 


MinRequestTimeout time.Duration 


我 们 注意 到 APIGroupVersion 是 与 rest.Storage Mapi, FAA 
定 了 相应 版 本 的 Codec、Convertor 用 于 版 本 转换 ， 这 样 就 很 容易 理解 
Kubemetes 是 怎样 区 分 多 版 本 API 的 Rest 服 务 的 。 以 下 是 过 程 详解 。 


H- XE 在  APIGroupVersion J  InstallREST 

(container*restful.Container) 方法 里 ， 用 Version 变 量 来 构造 一 个 Rest 

API Path 前 级 并 赋值 给 APIINstaller 的 prefix 变 量 ， 并 调用 它 的 Install 
() 方法 完成 Rest API 的 转换 ， 代 码 如 下 : 


func (g *APIGroupVersion) InstallREST(container 
*restful.Container) error { 
info :二 
&APIRequestInfoResolver[util.NewStringSet(strings.TrimPrefi 
x(g.Root,"/")), g.Mapper} 
prefix :- path.Join(g.Root, g.Version) 


installer :- &APIInstaller{ 


group: g, 
info: info, 
prefix: prefix, 


minRequestTimeout: g.MinRequestTimeout, 


proxyDialerFn: g.ProxyDialerFn, 


ws, registrationErrors := installer.Install() 


container .Add(ws) 


接着 ， 在 APIInstaller 的 Install () 772 A prefix (API 版 本 ) 前 级 
生成 WebService 的 相对 根 路 径 : 


func (a *APIInstaller ) newWebService() 
*restful.WebService { 
ws := new(restful.WebService) 
ws.Path(a.prefix) 
ws.Doc("API at"+ a.prefix +"version"+ a.group.Version) 
// TODO: change to restful.MIME_JSON when we set 
content type in client 
ws.Consumes("*/*") 
ws.Produces(restful.MIME JSON) 


ws.ApiVersion(a.group.Version) 


return ws 


最 后 ， 在 Kubernetes 的 Master 初 始 化 方法 func (m*Master) init 
(c*Config) 里 生成 不 同 的 APIGroupVersion 对 象 ， 并 调用 InstallRest 
O 方法 ， 完 成 最 终 的 多 版 本 API 的 Rest 服 务 装配 流程 : 


if m.vibeta3 { 
if err : = 


m.api_vibeta3().InstallREST(m.handlerContainer); err !- nil 


glog.Fatalf("Unable to setup API vibeta3: 
9, v", err) 
} 
apiVersions = append(apiVersions, "vibeta3") 
} 
if m.vi { 
if err : = 
m.api_vi().InstallREST(m.handlerContainer); err !- nil { 
glog.Fatalf("Unable to setup API vi: %v", 
err) 
} 


apiVersions = append(apiVersions, "v1") 


至 此 ，Rest API 的 多 版 本 问题 还 有 最 后 一 个 需要 漆 清 ， 即 在 不 同 
的 版 本 中 接口 的 输入 输出 参数 的 格式 是 有 差别 的 ，Kubemetes 是 怎么 
处 理 这 个 问题 的 ? 


要 和 弄 明 日 这 一 点 ， 我 们 首先 要 研究 KubernetesAPI 里 的 数据 对 象 的 
序列 化 、 反 序列 化 的 实现 机 制 。 为 了 同时 解决 数据 对 象 的 序列 化 、 反 
序列 化 与 多 版 本 数据 对 象 的 兼容 和 转换 问题 ，Kubernetes 设 计 了 一 父 
复杂 的 机 制 ， 首 先 ， 它 设计 了 conversion.Scheme x “> 24 $5 £i 

(pkg/conversion/schema.go#) ， 以 下 是 对 它 的 定义 : 


// Scheme defines an entire encoding and decoding 


scheme. 


type Scheme struct { 
// versionMap allows one to figure out the go type 
of an object //with the given version and name. 
versionMap map[string]map[string]reflect.Type 
// typeToVersion allows one to figure out the 
version for a given //go object The reflect.Type we index 
by should *not* be a pointer. If the same type 
// is registered for multiple versions, the last 
one wins. 
typeToVersion map[reflect.Type]string 
// typeToKind allows one to figure out the desired 
"kind" field //for a given go object. Requirements and 
caveats are the same as typeToVersion. 
typeToKind map[reflect.Type][]string 
// converter stores all registered conversion 
functions. It also //has default coverting behavior. 
converter *Converter 
// cloner stores all registered copy functions. It 
also has default 
// deep copy behavior. 
cloner *Cloner 
// Indent will cause the JSON output from Encode 
to be indented, iff it is true. 
Indent bool 
// InternalVersion is the default internal 
version. It is recommended that 


// you use "" for the internal version. 


InternalVersion string 
// MetaInsertionFactory is used to create an 
object to store and retrieve 
// the version and kind information for all 
objects. The default // uses the keys "apiVersion" and 
"kind" respectively. 


MetaFactory MetaFactory 


fe Efe Rr a DUE S], typeToVersion 5 versionMap/& the 7J T 
解决 数据 对 象 的 序列 化 与 反 序 列 化 问题 ，converter 属 性 则 负责 不 同 版 
本 的 数据 对 象 转换 问题 ，Kubernetes 这 个 设计 思路 人 徐 单 方便 地 解决 了 
多 版 本 的 序列 化 和 数据 转换 问题 ， 不 得 不 赞 ! 下 面 是 
conversion.Scheme 里 序列 化 、 反 序列 化 的 核心 方法 NewObject () 的 代 
码 : 通过 查找 versionMap 里 匹配 的 注册 类 型 ， 以 反射 方式 生成 一 个 空 
的 数据 对 象 : 


func (s *Scheme) NewObject(versionName, kind string) 
(interface{}, error) { 
if types, ok := s.versionMap[versionName]; ok { 
if t, ok := types[kind]; ok { 


return reflect.New(t).Interface(), nil 


return nil, &notRegisteredErr{kind: kind, 
version: versionName} 


j 


return nil, &notRegisteredErr{kind: kind, version: 


versionName } 


J 


Id pkg/conversion/encode.go 5j decode.go ll] f£ conversion.Schemefe (t 
的 基础 功能 之 上 ， 完 成 了 最 终 的 序列 化 、 反 序列 化 功能 。 下 面 古 
encode.go 里 的 主 方法 EncodeToVersion (..) 的 关键 代码 片段 : 


// 人 确定 要 转换 的 源 对 象 的 版 本 号 和 类 别 
objVersion, objKind, err :二 
s.ObjectVersionAndKind(obj) & 
// 生 成 目标 版 本 的 空 对 象 
objOut, err := s.NewObject(destVersion, objKind) 
// 生 成 转换 过 程 中 所 需 的 Metadata 信 息 


flags, meta := s.generateConvertMeta(objVersion, 


destVersion, obj) 
// 调 用 converter 的 方法 将 源 对 象 的 数据 填充 到 目标 对 象 objOut 
err = s.converter.Convert(obj, objOut, flags, meta) 
// 用 JSON 将 目标 对 象 转换 成 byte[] 数 组 ， 完 成 序列 化 过 程 


data, err = json.Marshal(obj) 


再 进一步 ，Kubernetes 在 conversion.Scheme 的 基础 上 又 做 了 一 个 孝 
活 工 具 类 runtime.Scheme ， 可 以 看 作 前 者 的 代理 类 ， 主 要 增加 了 
fieldLabelConversionFuncs 这 个 Map 属 性 ， 用 于 解决 数据 对 象 的 属性 名 
称 的 兼容 性 转换 和 校 验 ， 比 如 将 需要 兼容 Pod 的 spec.host 属 性 改 为 
spec.nodeName 的 情况 。 


注意 到 conversion.Scheme 只 是 实现 了 一 个 序列 化 与 类 型 转换 的 框 
娘 API， 提 供 了 注册 资源 数据 类 型 与 转换 函数 的 功能 ， 那 么 具体 的 资 
WR Te TRAE RRA NEEM SABRE? 答案 是 
pkg/api。Kubernetes 为 不 同 的 API 了 版 本 提供 了 独立 的 数据 类 型 和 相关 的 
BE He EN BX FE Pz BA hy AR fp Package, "lpkg/api/vl ` pkg/api/v1beta3 
等 ， 而 当前 默认 版 本 (内 部 版 本 ) 则 存在 于 pkg/api 目 录 下 。 


以 pkg/api/v1 为 例 ， 在 每 个 目录 里 都 包括 如 下 关键 源码 : 


types.go 定 义 了 Rest API 接 口 里 所 涉及 的 所 有 数据 类 型 ，v1 和 版 本 有 
2000 行 代码 ; 

在 “conversion.go 与 conversion generated.go 里 定义 了 
conversion.Scheme 所 需 的 从 内 部 版 本 到 v1 版 本 的 类 型 转换 函数 ， 
其 中 conversion_generated.go 中 的 代码 有 5000 行 之 多 ， 当 然 这 是 通 
过 工具 上 自动 生成 的 代码 ; 
register.go 负 责 将 types.go 里 定义 的 数据 类 型 与 conversion.go 里 定义 
的 数据 转换 函数 注册 到 runtime.Schema 里 。 


pkg/api 里 的 registergo 初始 化 生成 并 持 有 一 个 全 局 的 
runtime.Scheme 对 象 ， 并 将 当前 默认 版 本 的 数据 类 型 
(pkg/api/types.go) 注册 进去 ， 相 关 代 码 如 下 : 


var Scheme = runtime.NewScheme( ) 
func init() { 
Scheme.AddKnownTypes("", 
&Pod{}, 
&PodList{}, 


&PodStatusResult{}, 


&PodTemplate{}, 

&PodTemplateList{}, 

&ReplicationControllerList{}, 
// 此 次 省 略 30 多 个 数据 类 型 


&ServiceList{}, 


&Service(), 
&NodeList{}, 
&Node{}, 

// B 


MI pkg/api/v1/register.go 5j v1beta3 F H'Jregister.go EW 48 (4533: Fp 
j 把 与 版 本 相关 的 数据 类 型 和 转换 函数 注册 到 全 局 的 runtime.Scheme 


Mu 


E 


func init() { 
// Check if v1 is in the list of supported API 
versions. 
if !registered.IsRegisteredAPIVersion("vi") { 


return 


// Register the API. 
addKnownTypes( ) 
addConversionFuncs() 


addDefaultingFuncs() 


这 样 一 来 ， 其 他 地 方 都 可 以 通过 runtime.Scheme 这 个 全 局 变量 来 完 


成 Kubernetes API 中 的 数据 对 象 的 序列 化 和 反 序 列 化 逻辑 了 ， 比 如 
Kubernetes API Client 包 就 大 量 使 用 了 它 ， 下 面 是 pkg/client/pods.go 里 
Pod 删 除 的 Delete () 方法 的 代码 : 


// Delete takes the name of the pod, and returns an 


error if one occurs 


func (c *pods) Delete(name string, options 
*api.DeleteOptions) error { 
// TODO: to make this reusable in other client 
libraries 
if options == nil { 
return 
c.r.Delete().Namespace(c.ns).Resource("pods").Name(name).Do 
().Error() 
} 


body, err := api.Scheme.EncodeToVersion(options, 
c.r.APIVersion() ) 
if err != nil { 


return err 


return 
c.r.Delete().Namespace(c.ns).Resource("pods").Name(name) .Bo 
dy(body).Do().Error() 
} 


清楚 了 Kubernetes Rest API 中 的 数据 对 象 的 序列 化 机 制 及 多 版 本 的 
实现 原理 之 后 ， 我 们 接着 分 析 下 面 这 个 重要 流程 的 实现 细节 。 


Kubernetes 中 实 现 了 rest.Storage 接口 的 服务 在 转换 成 
restful.RouteFunction 以 后 ， 是 怎样 处 理 一 个 Rest 请 求 并 最 终 完 成 基于 后 
端 存 储 服务 etcd 上 的 具体 操作 过 程 的 ? 


H 25b, Kubemetes 设计 了 一 个 名 为 “注册 表 ” 的 Package 

(pkg/registry) ， 这 个 Package 按 照 rest.Storage 服 务 所 管理 的 资源 数据 

的 类 型 而 划分 为 不 同 的 子 包 ， 每 个 子 包 都 由 相同 命名 的 一 组 Golang 代 
码 来 完成 具体 的 Rest 接 口 的 实现 逻辑 。 


下 面 我 们 以 Pod 的 Rest 服 务实 现 为 例 ， 其 与 “注册 表 ” 相 关 的 代码 位 
于 pkg/registry/pod 中 ， 在 registry.go 里 定义 了 Pod 注 册 表 服务 的 接口 : 


type Registry interface { 
// ListPods obtains a list of pods having labels 
which match selector. 
ListPods(ctx api.Context, label labels.Selector) 
(*api.PodList, error) 
// Watch for new/changed/deleted pods 
WatchPods(ctx api.Context, label labels.Selector, 
field fields.Selector, resourceVersion string) 
(watch.Interface, error) 
// Get a specific pod 
GetPod(ctx api.Context, podID string) (*api.Pod, 
error) 


// Create a pod based on a specification. 


CreatePod(ctx api.Context, 
// Update an existing pod 
UpdatePod(ctx api.Context, 
// Delete an existing pod 


DeletePod(ctx api.Context, 


pod *api.Pod) error 


pod *api.Pod) error 


podID string) error 


j 


我 们 看 到 这 个 Pod 注 册 表 服务 是 针对 Pod 的 CRUD 的 操作 接口 的 一 
个 定义 ， 在 入 口 参 数 中 除了 调用 的 上 下 文 环境 api.Context， 束 是 我 们 
之 前 分 析 过 的 pkg/api 包 中 的 Pod 这 个 资源 数据 对 象 。 为 了 实现 强 类 型 
的 方法 调用 ， 在 registry.go 里 定义 了 一 个 名 为 storage 的 结构 体 ，storage 
实现 Registry 接 口 ， 可 以 看 作 一 种 代理 设计 模式 ， 因 为 具体 的 操作 都 是 
通过 内 部 rest.StandardStorage 来 实现 的 。 下 面 是 截取 的 registry.go 中 的 


create、update、delete 的 源码 : 


*storage) CreatePod(ctx api.Context, 


func (s 
*api.Pod) error { 
_, err := s.Create(ctx, 


return err 


func (s 
*api.Pod) error { 


err := s.Update(ctx, 


=f.) 


return err 


pod) 


*storage) UpdatePod(ctx api.Context, 


pod) 


pod 


pod 


func (s *storage) DeletePod(ctx api.Context, podID 
string) error { 
., err :- s.Delete(ctx, podID, nil) 


return err 


那么 ， 这 个 实现 了 rest.StandardStorage 通 用 接口 的 真正 Storage 又 是 
什么 ? 从 Master 对 象 的 初始 化 函数 中 ， 我 们 发 现 了 下 面 的 相关 代码 : 


func (m *Master) init(c *Config) { 
healthzChecks := []healthz.HealthzChecker{} 
m.clock = util.RealClock{} 
podStorage := podetcd.NewStorage(c.EtcdHelper, 
c.KubeletClient ) 


podRegistry := pod.NewRegistry(podStorage.Pod) 


Master 对 象 创建 了 一 个 私有 变量 podStorage， 其 类 型 为 PodStorage 
(pkg/registry/pod/etcd/etcd.go) ，Pod 注 册 表 服务 实例 (podRegistry) 
里 真正 的 Storage 是 podStorage.Pod。 下 面 是 podetcd 的 函数 NewStorage 中 

的 关键 代码 : 


func NewStorage(h tools.EtcdHelper, k 
client.ConnectionInfoGetter) PodStorage { 
store := &etcdgeneric.Etcd{ 
NewFunc: func() runtime.Object { return 
&api.Pod{} }, 


NewListFunc: func() runtime.Object { return 


&api.PodList{} }, 


return PodStorage{ 


Pod: &REST{*store}, 

Binding: &BindingREST{store: store}, 

Status: &StatusREST(store: &statusStore}, 
Log: &LOgREST{store: store, 


kubeletConn: k}, 
Proxy: &ProxyREST{store: store}, 
Exec: &ExecREST{store: store, 
kubeletConn: k}, 
PortForward: &PortForwardREST{store: store, 
kubeletConn: k}, 
} 


在 上 述 代 码 中 我 们 看 到 : 位 于 pkg/registry/generic/etcd/etcd.go 里 的 
etcd 才 是 真正 的 Storage 实 。 而 具体 操作 etcd 的 代码 是 靠 
tools.EtcdHelper 这 个 类 完成 的 ， 通 过 分 析 etcd.go 里 的 func (e*Etcd) 
Create (ctx api.Context, obj persed 方法 ， 我 们 知道 创建 一 个 
etcd 里 的 键 值 对 的 关键 逻辑 如 下 。 


。 获取 对 象 的 名 字 : name, err: =e.ObjectNameFunc (obj) ° 

。 获取 Key: key, err: =e.KeyFunc (ctx, name) ° 

。 生成 一 个 空 的 Object 对 象 : out: =e.NewFunc () ° 

。 将 键 值 对 写 入 etcd: TEe.Helper.CreateObj (key, obj, out, ttl) 77 
法 中 通过 调用 runtime.Codec 完 成 从 对 象 到 字符 串 的 转换 ， 最 终 保 
存 开 etcd 中 。 


。 回调 创建 完成 后 的 处 理 逻 辑 : e.AfterCreate (out) ° 


注意 到 之 前 PodStorage 创 建 store 时 重 载 了 ObjectNameFunc () ^ 
KeyFunc () 、NewFunc () 等 贸 数 ， 于 是 完成 了 针对 Pod 的 创建 过 
程 ，Kubernetes API 服 务 中 的 其 他 数据 对 象 也 都 遵循 同样 的 设计 模式 。 


进一步 研究 代码 ， 我 们 发 现 PodStorage 中 的 Pod、Binding ` Status 
等 属性 是 pkg/api/rest/rest.go 中 几 个 不 同 的 Rest 接 口 的 实现 ， 并 且 通 过 
etcdgeneric.Etcd 这 个 实例 来 完成 Pod 的 一 些 具体 操作 ， 比 如 这 里 的 
StatusREST。 下 面 是 其 相关 代码 户 段 : 


// StatusREST implements the REST endpoint for 
changing the status of a pod. 
type StatusREST struct ( 
store *etcdgeneric.Etcd 
} 
// New creates a new pod resource 
func (r *StatusREST) New() runtime.Object { 
return &api.Pod{} 
} 
// Update alters the status subset of an object. 
func (r *StatusREST) Update(ctx api.Context, obj 
runtime.Object) (runtime.Object, bool, error) { 


return r.store.Update(ctx, obj) 


X 6.2 展现 了 PodStorage 中 的 各 个 XXXREST 接口 与 
pkg/apirestrest.go 里 的 相关 Rest 接 口 的 一 一 对 应 关系 。 


#26.2 ”PodStorage 中 的 各 个 XXXREST 接 口 与 
pkg/api/rest/rest.go 里 的 相关 Rest 接 口 的 一 一 对 应 天 系 


PodStorage Rest 接口 对 应 API Rest 框架 的 接口 接口 功能 
rest.Redirector 重 定 向 资源 的 路 径 
rest.CreaterUpdater 资源 创建 、 更 新 接口 
rest.Lister 资源 列表 查询 接 


rest.Watcher 


rest. GracefulDeleter WHE REL 


rest.Getter 获取 具体 资 


BindingREST rest.Creater 创建 资源 的 接 


StatusREST Rest.Updater 更 新 资源 的 接 


LogREST rest.GetterWithOptions 获取 资源 的 接 


ExecREST\ProxyREST\ PortForwardREST rest.Connecter 连接 资源 的 接 


其 中 PodStorage.REST 接 口 究竟 实现 了 哪些 API Rest 接 口 ， 这 个 比 
较 隐 临 ， 笔 者 也 花费 了 一 些 时 间 来 研究 这 个 问题 ， 这 涉及 Go 语言 的 一 
个 特殊 特性 : 结构 体内 花 一 个 其 他 类 型 的 结构 体 指针 ， 残 可 以 使 用 内 
敬 结 构 体 的 方法 ， 相 当 于 面向 对 象 语言 中 的 “继承 ”。 而 
PodStorage.REST 18 18 ik Æ T etcdgeneric.Etcd 类 型 的 匿名 指针 : 
&REST{*store} ， 而 etcdgeneric.Etcd 则 实现 Y rest.Creater ` rest.Lister ^ 
rest.Watcher 等 资源 管理 接口 的 所 有 方法 ，PodStorage.REST 也 “继承 ”了 
Beku 


ix f] [B] 3 RE OA T gd xx EE 来 B apiinstalergo 的 
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creater, isCreater :- storage.(rest.Creater) 
namedCreater, isNamedCreater := storage. 
(rest .NamedCreater ) 
lister, isLister := storage.(rest.Lister) 


getter, isGetter := storage.(rest.Getter) 


getterWithOptions, isGetterWithOptions := storage. 
(rest.GetterWithOptions) 
deleter, isDeleter :- storage.(rest.Deleter) 
gracefulDeleter, isGracefulDeleter :- storage. 
(rest.GracefulDeleter) 
updater, isUpdater :- storage.(rest.Updater) 
patcher, isPatcher :- storage.(rest.Patcher) 
watcher, isWatcher :- storage.(rest.Watcher) 
., isRedirector :- storage.(rest.Redirector) 
connecter, isConnecter :- storage.(rest.Connecter) 
storageMeta,  isMetadata := storage. 


(rest.StorageMetadata) 


上 述 代 码 对 storage 对 象 进 行 判断 ， 以 确定 并 标记 它 所 满足 的 
APIRest 接 口 类 型 ， 而 接 下 来 的 这 段 代 人 码 在 此 基础 上 确定 此 接口 所 包含 
的 actions , 后 者 则 对 应 到 某 种 HTTP WK FE 
( GET/POST/PUT/DELETE ) 或 者 HITP PROXY ^ WATCH ^ 
CONNECT 等 动作 : 


ctions = appendIf(actions, action{"GET", itemPath, 
nameParams, namer}, isGetter) 
actions = appendIf(actions, action{"PATCH", itemPath, 
nameParams, namer}, isPatcher) 
actions = appendIf(actions, action{"DELETE", itemPath, 
nameParams, namer}, isDeleter) 
actions = appendIf(actions, action{"WATCH", "watch/" + 


itemPath, nameParams, namer}, isWatcher) 


actions = appendIf(actions, action{"PROXY", "proxy/" + 
itemPath + "/{path:*}", proxyParams, namer}, isRedirector) 
actions =  appendlIf(actions, action{"CONNECT", 


itemPath, nameParams, namer}, isConnecter) 


我 们 注意 到 rest.Redirector 类 型 的 storage 被 当 作 PROXY 进 行 处 理 ， 
由 apiserver.ProxyHandler i fT T5 #& , Jf Val AA restRedirector 的 
ResourceLocation 方 法 获取 到 资源 的 处 理 路 径 (可 能 包括 一 个 非 空 的 
http.RoundTripper ， 用 于 处 理 执行 Redirector 返 回 的 URL 请 求 ) 。 
Kubernetes API Server 中 PROXY 请 求 存 在 的 意义 在 于 透明 地 访问 其 他 
某 个 市 点 (比如 某 个 Minion) 上 的 API。 


最 后 ， 我 们 来 分 析 下 registerResourceHandlers 中 完成 从 rest.Storage 
到 restful.Route 上 映射 的 最 后 一 段 天 键 代码 。 下 面 是 rest.Getter 接 口 的 
Storage 的 映射 代码 : 


case "GET": // Get a resource. 
var handler restful.RouteFunction 
handler = GetResource(getter, reqScope) 
doc := "read the specified " + kind 
route :二 
ws.GET(action.Path).To(handler).Filter(m).Doc(doc). 
Param(ws.QueryParameter("pretty", "If 'true', then the 


output is pretty printed.")). 


Operation("read"+namespaced+kind+strings.Title(subresource) 


j; 


Produces(append(storageMeta.ProducesMIMETypes(action.Verb), 
"application/json")...). 
Returns(http.StatusOK, "OK", 


versionedObject).Writes(versionedObject) 


addParams(route, action.Params) 


ws.Route(route) 


EI 4 85 E JOE of E XX GetResource () 创建 了 一 个 
restful.RouteFunction, ， 然 后 生成 一 个 restfulroute 对 象 ， 最 后 注册 到 
restful.WebService 中 ， 从 而 完成 了 rest.Storage 到 Rest 服 务 的 “最 后 一 公 
里 ”通车 。GetResource () K T pkg/apiserver/resthandler.go Et , 
resthandler.go 提 供 了 各 种 具体 的 restful.RouteFunction 的 实现 函数 ， 是 真 
正 触发 rest.Storage 调 用 的 地 方 。 下 面 是 GetResource () 方法 的 主要 代 
码 ， 可 以 看 出 这 里 是 调用 rest.Getter 接 口 的 Get () 方法 以 返回 某 个 资 
源 对 象 : 


func GetResource(r rest.Getter, scope RequestScope) 
restful.RouteFunction { 
return getResourceHandler (scope, 
func(ctx api.Context, name string, req 
*restful.Request) (runtime.Object, error) { 


return r.Get(ctx, name) 


}) 


看 了 上 面 的 代码 ， 你 可 能 会 有 一 个 疑问 : “说 好 的 权限 控制 
Ug? ” 别 急 ， 看 看 下 面 的 资源 创建 的 createHandler () 代码 : 


if admit.Handles(admission.Create) { 
userInfo, _ :- api.UserFrom(ctx) 
err - 
admit.Admit(admission.NewAttributesRecord(obj, scope.Kind, 
namespace, name, scope.Resource, scope.Subresource, 
admission.Create, userInfo)) 
if err != nil ( 
errorJSON(err, scope.Codec, w) 


return 


资源 的 Update、Delete、Connect、Patch 等 操作 都 有 类 似 的 权限 控 
制 ， 从 Admit 的 参数 admission.Attributes 的 属性 来 看 ， 第 三 方 系统 可 以 
开发 细 粒 度 的 权限 控制 插件 ， 针 对 任意 资源 的 任意 属性 进行 细 粒 度 的 
权限 控制 ， 因 为 资源 对 象 本 和 喘 都 传递 到 参数 中 了 。 


对 Kubernetes Rest API Server 的 复杂 实现 机 制 和 调用 流程 的 总 结 如 
Fe 


。 在 pkg/api 包 里 定义 了 Rest API 中 涉及 的 资源 对 象 、 提 供 的 Rest 接 
口 、 类 型 转换 框架 和 有 具体 转换 函数 、 序 列 化 反 序列 化 等 代码 。 其 
中 ， 资 源 对 象 和 转换 函数 按照 版 本 分 包 ， 形 成 了 Kubernetes API 
Server 基 础 的 框架 ， 其 中 核心 是 各 类 资源 (如 Node、Pod、 


PodTemplate ` Services ) 及 这 些 资 源 对 应 的 rest.Storage (Rest 
API 接 口 ) 。 

在 pkg/runtime 包 里 最 重要 的 对 象 是 Schema， 它 保存 了 Kubernetes 
API Service 中 注册 的 资源 对 象 类 型 、 转 换 函 数 等 重要 基础 数据 。 

男 外 ，runtime 包 也 提供 了 获取 json/yaml 序 列 化 、 反 序列 化 的 
Codec 结 构 体 ，runtime 总 体 上 与 pkg/api 密 切 关 联 ， 分 离 出 来 的 目 
的 是 供 其 他 模块 方便 使 用 。 

pkg/registry 包 其 实 是 把 pkg/api 中 定义 的 各 种 资源 对 象 所 提供 的 
Rest 接口 进一步 规范 定义 并 且 实 现 对 应 的 接口 ， 其 中 
generate/etcd/etcd.go 里 的 etcd 对 象 是 一 个 真正 实现 了 rest.Storage 接 
口 的 基于 etcd 后 端 存储 的 服务 TE^ ， 并 且 Kubernetes 中 的 各 种 资源 
对 象 的 具体 Storage 实 现 也 是 通过 它 来 完成 真正 的 “后 端 存储 操 
[peg 

Kubemetes?K H T go-restful 这 个 第 三 方 的 Rest 框 架 ， 大 大 简化 了 
Rest 服 务 的 开发 ， 主 要 代码 在 pkg/apiserver 源 人 码 包 里 。 通 过 
APIGroup Version 3X ^ 24 15] f n] 75 B, 7S [8] API hig AS BJ Rest ER 12 BR 
射 ， 而 api_installer.go 则 实现 了 从 Kubernetes Rest.Storage 接 口 到 go- 
restful HY) HR OY ye fe 39 48 , X 应 rest.Storage 的 具体 
restful.RouteFunction 则 在 resthandler.go 里 实现 。 
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HE DMI HY 6.2.1 19 NAWE, 357 E A IE MAI F Kubernetes API 
Server 的 设计 的 第 一 个 评价 就 是 : “KER ARARAT) Bie 
Rest Server 么 ， 如 果 用 Java 语 言 ， 我 可 以 分 分 钟 搞定 一 个 ! ”当然 ， 你 


肯定 


有 以 下 或 者 更 多 的 假设 。 


放弃 多 版 本 API 的 兼容 需求 。 

只 采用 一 个 特定 的 后 端 存 储 实 现 。 

API 只 接收 一 种 输入 输出 格式 ， 比 如 JSON 或 者 YAML ， 而 不 是 两 
种 或 更 多 。 

放弃 Watch 这 种 高 难度 的 API 。 

不 实现 Proxy 代 理 。 

不 做 可 拔 插 的 权限 控制 设计 (或 者 根本 没有 ) 。 

每 新 增 一 种 资源 类 型 ， 束 从 头 写 很 多 代码 来 实现 该 资源 的 Rest 服 


务 。 


虽然 代码 很 复杂 ， 但 我 们 不 得 不 承认 ，Kubernetes API Server 是 一 


个 精心 “设计 ”的 系统 。 


什么 样 的 设计 是 一 个 好 的 设计 ? 这 个 问题 没有 标准 答案 ， 但 有 一 


扩 是 大 家 痢 认 可 的 :好 的 设计 要 尽量 提供 一 种 好 的 框架 机 制 ， 方 便 未 
来 增加 新 功能 或 者 目 定 义 扩 展 某 些 特性 。 我 们 以 这 个 标准 对 


Kubernetes API Server 的 设计 进行 评价 ， 束 会 发 现 : 它 的 设计 真 的 很 
好 。 


我 们 先 分 析 一 下 Kubernetes API Server 的 “领域 模型 ”。API Server 
里 的 Rest 服 务 都 是 针对 某 个 “资源 对 象 ” 的 操作 ， 这 些 操 作 可 以 分 为 新 
增 、 人 修改、 列表 输出 、 删 除 、Watch 变 化 、 代 理 请 求 及 连接 资源 等 基础 
操作 ， 大 多 数 操 作 都 是 与 后 端 存储 的 交互 。 因 为 只 是 基本 的 资源 数据 
对 象 的 增 、 删 、 改 、 查 ， 所 以 主体 逻辑 是 通用 的 ， 比 如 序列 化 、 反 序 
列 化 、 基 于 Key-Value 的 存储 ， 以 及 这 个 过 程 中 的 数据 校 验 和 权限 控制 


FY ay 
等 问题 。 


通过 以 上 分 析 ， 我 们 发 现 这 个 系统 的 核心 对 象 只 有 两 个 : 资源 对 
象 与 操作 资源 对 象 的 Storage 服 务 。 虽 然 各 个 资源 的 Storage 服 务 的 主体 
功能 相同 ， 都 是 将 资源 存储 到 etcd 这 个 Key-Value 后 端 存储 系统 上 并 提 
供 相 关 操 作 ， 但 不 同类 型 资源 的 Storage 服 务 的 接口 和 具体 逻辑 还 是 有 
差别 的 ， 比 如 某 类 资源 是 不 允许 更 新 的 ， 有 些 资源 则 允许 “Connect”， 
所 以 这 里 的 设计 是 Kubernetes API Server 的 最 有 代表 性 的 经 典 设计 一 一 
资源 服务 接口 的 细 分 与 组 合 设 计 。 


如 图 6.2 所 示 是 此 设计 的 全 景 图 (以 Pod 资 源 对 象 为 例 ) 。 资 源 服 
务 接 口 被 拆 分 为 rest.Create ^ rest.Updater ` rest.CreateUpdate. (组 合 了 
Create 与 Updater 接 口 ) 、rest.GracefulDelete (支持 延迟 删除 资源 的 接 
L1) 、rest.Patcher (组 合 更 新 与 Get 接 口 ) 、rest.Connect (开启 HTTP 
连接 到 该 资源 进行 操作 ， 比 如 连接 到 一 个 Pod 中 执行 某 个 bash 命 令 ) 等 
10 个 细 分 接口 。 


考虑 到 大 多 数 资源 对 象 都 需要 基本 的 CRUD 接 口 ， 这 融 是 
rest.StandardStorage 这 个 聚合 型 “标准 存储 服务 ”接口 出 现 的 原因 。 而 作 


为 StandardStorage 的 默认 实现 ，pkg/registry/generic/etcd/etcd.go 里 etcd 这 
个 对 象 实 现 了 基于 etcd 后 端 存储 的 所 有 具体 操作 ， 而 各 种 资源 的 
Storage 服 务 则 通过 将 请 求 代理 到 etcd 对 象 上 来 完成 具体 的 功能 。 


这 里 有 点 让 人 难以 理解 的 是 PodStorage 与 它 的 属性 Pod 的 关系 ， 其 
实 PodStorage 这 个 对 象 是 一 个 聚合 了 与 Pod 相 关 的 各 个 资源 的 存储 服 
务 ， 多 看 一 下 它 的 定义 就 能 立刻 明白 了 : 


// PodStorage includes storage for pods and all sub 
resources 


type PodStorage struct { 


Pod *REST 
Binding *BindingREST 
Status *StatusREST 
Log *LogREST 
Proxy *ProxyREST 
Exec *ExecREST 


PortForward *PortForwardREST 


rest.Create rest. Updater rest.GracefulDeleter 


rest.Getter 
rest.CreateUpdate 
Ma rest.Lister 


rest.StandardStorage 
rest. Watcher 
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rest.Redirector rest.Connecter 


图 6.2 API Server 的 Storage 设 计 全 景 图 


所 以 ， 这 里 的 PodStorage 应 该 重 命名 为 AllPodResStorage， 而 真正 
的 PodStorage 上 就 是 里 面 的 那个 Pod 变 量 ， 这 个 变量 是 对 etcd 实 例 的 一 
个 引用 ， 然 后 又 实现 了 rest.Redirector 接 口 。 现 在 你 终于 能 理解 
PodRegistry 引 用 Pod 变 量 而 不 是 PodStorage 来 实现 Pod 操 作 的 真正 原 
了 吧 ? 


最 后 ， 我 们 来 说 说 PodRegistry 存 在 的 目的 。 从 之 前 的 代码 分 析 来 

看 ， 一 个 来 自 外 部 的 针对 某 个 资源 的 Rest API 发 起 的 请 求 最 后 落 到 对 
Ny 资源 的 rest.Storage 对 象 上 ， 由 restful.RouteFunction 调 用 此 对 象 的 相关 
(EAR RAVER EFF E BINE [RARE m, UT CERA XC VP 
对 应 资源 的 Registry 服 务 。 那 么 问题 来 了 了， 资源 的 Registry 接 口 存在 的 


理由 是 什么 呢 ? 答案 很 简单 ， 对 比 Storage 接 口 与 Registry 中 的 资源 创建 
方法 的 签名 ， 下 面 是 二 者 的 源码 对 比 ， 后 者 更 符合 “手工 调用 ” 


Storage 中 创建 通用 的 资源 对 象 的 接口 


Create(ctx  api.Context, obj  runtime.Object) 


(runtime.Object, error) 


PodRegistry 中 创建 Pod 资 源 的 接 


Il 


CreatePod(ctx api.Context, pod *api.Pod) error 


f£ Kubernetes API Server 中 为 每 类 资源 都 创建 并 提供 了 一 个 
Registry 接 口服 务 的 目的 是 供 内 部 模块 的 编程 使 用 ， 而 非 对 外 提供 服 
务 ， 很 多 文档 都 错误 理解 了 这 个 问题 。 


本 节 最 后 给 出 了 如 图 6.3 所 示 的 经 典 的 Kubemetes 的 Master 闻 点 数 
据 流 图 ， 此 刻 这 个 图 在 你 眼 里 可 能 已 经 什么 都 不 算 了 ， 因 为 你 已 经 润 
穿 了 幕后 的 一 切 。 


Etcd Registry 
Storage 
Registry Storage 


图 6.3 Master 节点 数据 流 


6.3 kube-controller-managerZt £z ijf 7) AT 


iB 11 f£ Master P A E BJ 58 271 XE EE BL ze kube-controller-manager JF 
fz, EUController Manager Server，Kubernetes 的 核心 进程 之 一 ， 其 主要 
目的 是 实现 Kubernetes 集 群 的 故障 检测 和 恢复 的 自动 化 工作 ， 比 如 内 
Hb ZH fF EndpointController# ti] a& f 51 Endpoints Xf 25 B5) 81] £& 4158 397 ; 
ReplicationManager 根 据 注册 表 中 的 ReplicationController 的 定义 ， 完 成 
Pod 的 复制 或 者 移 除 ， 以 确保 复制 数量 的 一 致 性 ;NodeController 负 责 
Minion 市 点 的 发 现 、 管 理 和 监控 。 


6.3.1 进程 局 动 过 程 


kube-controller-manager 进 程 的 入 口 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube- 


controller-manager/ controller -manager ,go 


ALHmain () 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS(runtime.NumCPU( ) ) 
S := app.NewCMServer() 
s.AddFlags(pflag.CommandLine) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err :- s.Run(pflag.CommandLine.Args()); err !- 
nil { 
fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 


从 源码 可 以 看 出 ， 天 键 代码 只 有 两 行 ， 创 建 一 个 CMServer 并 调用 
Run 方 法 启动 服务 。 下 面 我 们 分 析 CMServer 这 个 结构 体 ， 它 是 
Controller Manager Server 进 程 的 主要 上 下 文 数据 结构 ， 存 放 一 些 关 键 
参数 ， 表 6.3 是 对 CMServer 里 的 关键 参数 的 解释 。 


表 6.3 ”CMServer 的 重要 属性 


属 性 名 ER i * 义 
ConcurrentEndpointSyncs 5 秒 并 发 执行 的 Endpoint 的 同步 任务 的 数量 


ConcurrentRCSyncs 5 秒 并 发 执行 的 Replication Controller 的 同步 任务 的 数量 


NodeSyncPeriod sh 从 CloudProvider 处 同步 Node 节点 的 周期 


NodeMonitorPeriod 5 秒 Node 节点 监控 的 周期 
ResourceQuotaSyncPeriod 对 资源 的 配额 使 用 情况 进行 同步 的 周期 


NamespaceSyncPeriod 5 分钟 Namespace 同步 的 周期 
PVClaimBinderSyncPeriod 2 对 PV (持久 存储 ) 和 PV 的 申请 进行 同步 的 周期 
PodEvictionTimeout 5 分 钟 在 Node 失败 的 情况 下 ， 其 上 的 Pod 多 入 后 才 被 删除 


master Kubernetes API Server 的 访问 地 址 


从 上 述 这 些 变量 来 看 ，Controller Manager Server 其 实 就 是 一 个 “ 超 
级 调度 中 心 *， 它 负责 定期 同步 Node 市 点 状态 、 资 源 使 用 配额 信息 、 
Replication Conctroller ` Namespace ` Pod JPVZ XE fa, te Atal 
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S o 


在 controller-manager.go 里 创建 CMServer 实 例 并 把 参数 从 命令 行 中 
传递 到 CMServer 后 ， 就 调用 它 的 func (s*CMServer) Run (_[]string) 
方法 进入 关键 流程 ， 这 里 首先 创建 一 个 Rest Client 对 象 用 于 访问 
Kubernetes API Server 提 供 的 API 服 务 : 


kubeClient, err := client.New(kubeconfig) 
if err !- nil ( 


glog.Fatalf("Invalid API configuration: %v", 


err) 


随后 ， 创 建 一 个 HTTP Server 以 提供 必要 的 性 能 分 析 (Performance 
Profile) 和 性 能 指标 度量 (Metrics) 的 Rest 服 务 : 


go func() { 
mux := http.NewServeMux() 
healthz.InstallHandler (mux) 
if s.EnableProfiling { 
mux.HandleFunc("/debug/pprof/", 
pprof.Index) 
mux.HandleFunc("/debug/pprof/profile", 
pprof.Profile) 
mux.HandleFunc("/debug/pprof/symbol", 
pprof.Symbol) 
} 


mux.Handle("/metrics", prometheus.Handler()) 


server :- &http.Server( 
Addr: 
net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), 
Handler: mux, 


j 


glog.Fatal(server.ListenAndServe()) 


3() 


我 们 注意 到 性 能 分 析 的 Rest 路 径 是 以 /debug 开 头 的 ， 表 明 是 为 了 程 
序 调 试 所 用 ， 事 实 上 的 确 如 此 ， 这 里 的 几 个 Profile 选 项 都 是 针对 当前 
Go 进程 的 Profile 数 据 ， 比 如 我 们 在 Master 节 点 上 执行 curl 命 令 (地 址 为 
http://127.0.0.1: 10252/debug/pprof/heap) 可 以 获取 进程 的 当前 堆栈 信 
息 ， 会 输出 如 下 信息 ; 


heap profile: 4: 78112 [1109: 824584] @ heap/1048576 
1: 32768 [1: 32768] Q9 0x402612 0x75ab95 0x771419 
0x771379 O0x565f08 O0x46133f Ox400d10 0x4155a3 0x43e711 
1: 32768 [1: 32768] Q9 0x408806 0x407968 0x97e591 
0x9895aa  0x76099b  Oxa2f400  0xa4e887 Ox765dc4  Ox557fbc 
0x782fac Ox5fe5db  0x602ca7  0x462c92  0Ox400f06  0x415594 
0x43e711 
1: 12288 [1: 12288] @ Ox4199fc Ox7df75d Ox5b585c 
Ox5b4947  Ox5b405a  0x5aa472 Ox5aa2b7  0x5aa188 Ox5ad0d3 
Ox46291e 0x43e711 
1: 288 [1: 288] @ Ox415d6a 0x43276f Ox43510f Ox42fd37 


Ox4311f9 Ox430ef5 0x43c136 


其 他 还 有 GC 回收 、Symbol 查 看 、 进 程 30 秒 内 的 CPU 利 用 率 、 协 程 
的 阻塞 状态 等 Profile 功 能 ， 输 出 的 数据 格式 符合 google-perftools 这 个 工 
具 的 要 求 ， 因 此 可 以 做 运行 期 的 可 视 化 Profile， 以 便 排 查 当 前 进程 潜 
在 的 问题 或 性 能 瓶颈 o 


性 能 指标 度量 目前 主要 收集 和 统计 Kubernetes API Server 的 Rest 
API 的 调用 情况 ， 执 行 curl (http://127.0.0.1: 10252/metrics) ， 可 以 看 
到 输出 中 包括 大 量 类 似 下 面 的 内 容 : 


rest_client_request_latency_microseconds{url="http://centos 


master :8080/api/vi/namespaces/default/endpoints/%3Cname%3E" 


,verb="GET", quantile="0.5"} 1448 


rest_client_request_latency_microseconds{url="http://centos 


master :8080/api/vi/namespaces/default/endpoints/%3Cname%3E" 
,verb="GET", quantile="0.9"} 1699 


rest_client_request_latency_microseconds{url="http://centos 


master :8080/api/vi/namespaces/default/endpoints/%3Cname%3E" 
,verb="GET", quantile="0.99"} 2093 


这 些 指标 有 助 于 协助 发 现 Controller Manager Server 在 调度 方面 的 
性 能 瓶颈 ， 因 此 可 以 理解 为 什么 会 被 包括 到 进程 代码 中 去 。 


接 下 来 ， 启 动 流 程 进入 到 关键 代码 部 分 。 在 这 里 ， 启 动 进程 分 别 
创建 如 下 控制 姻 ， 这 些 控制 絮 的 主要 目的 是 实现 资源 在 Kubemetes API 
Server 的 注册 表 中 的 周期 性 同步 工作 : 


。 EndointController 人 负责 对 注册 表 中 的 Kubernetes Service 的 Endpoints 
AAW IR] a LE; 
e ReplicationManager#h 28 33: Ht z& F Xf ReplicationController HE X. , 
完成 Pod 的 复制 或 者 移 除 ， 以 确保 复制 数量 的 一 致 性 ; 


作 ， 


NodeController 则 通过 CloudProvider 的 接口 完成 Node 实 例 的 同步 工 
f£; 

servicecontroller 通 过 CloudProvider 的 接口 完成 云 平台 中 的 服务 的 
同步 工作 ， 这 些 服 务 目前 主要 是 外 部 的 负载 均衡 服务 ; 
ResourceQuotaManager 负 责 资 源 配额 使 用 情况 的 同步 工作 ; 
NamespaceManager 负 责 Namespace 的 同步 工作 ; 


PersistentVolumeClaimBinder 与 PersistentVolumeRecycler 分 别 完 成 


PersistentVolume 的 绑 定 和 回收 工作 ; 
TokensController 、ServiceAccountsController 分 别 完 成 Kubernetes 服 
务 的 Token、Account 的 同步 工作 。 


创建 并 局 动 完 成 上 述 的 控制 器 以 后 ， 各 个 控制 器 束 开 始 独立 工 


Controller Manager Server 局 动 完毕 。 


6.3.2 ”关键 代码 分 析 


在 6.3.1 世 对 kube-controller-manager 进 程 的 启动 过 程 进行 了 详细 分 
析 ， 我 们 发 现 这 个 进程 的 主要 逻辑 惑 是 局 动 一 系列 的 “控制 项 >”。 这 里 
以 Kubernetes 里 比较 关键 的 Pod 副 本 (Pod Replica) 数量 的 控制 实现 过 
程 为 例 ， 来 分 析 完 成 这 个 任务 的 “控制 器 ”一 一 ReplicationManager 具 体 
是 如 何 工作 的 。 


首先 ， 我 们 来 看 看 ReplicationManager 结 构 体 的 定义 : 


type ReplicationManager struct { 
kubeClient client.Interface 


podControl PodControlInterface 


// An rc is temporarily suspended after 
creating/deleting these many replicas. 
// It resumes normal action after observing the 
watch events for them. 
burstReplicas int 
// To allow injection of syncReplicationController 
for testing. 


syncHandler func(rcKey string) error 


// podStoreSynced returns true if the pod store 


has been synced at least once. 


// Added as a member to the struct to allow 
injection for testing. 


podStoreSynced func() bool 


// A TTLCache of pod creates/deletes each rc 
expects to see 
expectations RCExpectationsManager 
// A store of controllers, populated by the 
rcController 
controllerStore cache.StoreToControllerLister 
// A store of pods, populated by the podController 
podStore cache.StoreToPodLister 
// Watches changes to all replication controllers 
rcController *framework.Controller 
// Watches changes to all pods 
podController *framework.Controller 
// Controllers that need to be updated 


queue *workqueue.Type 


在 上 述 结构 体 里 ， 比 较 关 键 的 几 个 属性 如 下 。 


e kubeClient: 用 来 访问 KubernetesAPIServer 的 Rest 客 户 端 ， 这 里 用 
来 访问 注册 表 中 定义 的 ReplicationController 对 象 并 操作 Pod ° 

e podControl: 实现 了 Pod 副 本 创建 的 落 数 ， 其 实现 类 为 
RealPodControl ( 位 于 


kubernetes/pkg/controller/controller_utils.go) ° 


syncHandler: 是 RC (ReplicationController) 的 同步 实现 方法 ， 完 
成 具体 的 RC 同步 逻辑 (创建 Pod 副 本 时 调用 PodControl 的 相关 方 
法 ) ， 在 RA E 中 其 被 WM d 为 
ReplicationManager.syncReplicationController 方 法 。 

e expectations: 是 Pod 副 本 在 创建 、 删 除 过 程 中 的 流 控 机 制 的 重要 
组 成 部 分 。 

controllerStore: 是 一 个 具备 本 地 缓存 功能 的 通用 的 资源 存储 服 
务 ， 这 里 存放 framework.Controller 运 行 过 程 中 从 Kubernetes API 
Server 同 步 过 来 的 资源 数据 ， 目 的 是 减轻 资源 同步 过 程 中 对 
Kubernetes API Server 造 成 的 访问 压力 并 提高 资源 同步 的 效率 。 
rcController: framework.Controller 的 一 个 实例 ， 用 来 实现 RC 同步 
的 任务 调度 逻辑 。 

framework.Controller: 是 kube-controller-manager 里 设计 的 用 于 资 
WRT AR [n] 2 XE ERR A EV EER e 

podStore: 类 似 于 controllerStore 的 作用 ， 用 来 存 取 和 获取 Pod 资 源 
NR o 

podController: 类 似 于 rcController 的 作用 ， 用 来 实现 Pod 同 步 的 任 
务 调度 逻辑 。 


理解 了 ReplicationManager 结 构 体 的 重要 参数 及 其 作用 之 后 ， 我 们 
来 看 controllerNewReplicationManager ( kubeClient client.Interface , 
burstReplicas int) *ReplicationManager 这 个 构造 函数 中 的 关键 代码 ， 注 
意 到 这 里 通过 调用 framework.NewInformer () 方法 先后 创建 了 用 于 RC 
同步 及 Pod 同 步 的 framework.Controller。 下面 是 framework.NewInformer 
() 方法 的 源码 : 


func NewInformer ( 
lw cache.ListerWatcher, 
objType runtime.Object, 
resyncPeriod time.Duration, 
h ResourceEventHandler, 
) (cache.Store, *Controller) { 
clientState 
cache.NewStore(DeletionHandlingMetaNamespaceKeyFunc ) 


fifo 


cache.NewDeltaFIFO(cache.MetaNamespaceKeyFunc, nil, 


clientState) 


cfg := &Config{ 


Queue: fifo, 
ListerWatcher: lw, 
ObjectType: objType, 


FullResyncPeriod: resyncPeriod, 
RetryOnError: false, 
Process: func(obj interface{}) error { 
// from oldest to newest 
for _, d := range obj.(cache.Deltas) { 


switch d.Type { 


case cache.Sync, cache.Added, 


cache.Updated: 
if old, exists, err 
clientState.Get(d.Object); err == nil && exists { 


if err 


clientState.Update(d.Object); err != nil { 


return err 


} 
h.OnUpdate(old, d.Object) 
) else ( 
if err :- 
clientState.Add(d.Object); err != nil { 
return err 
} 
h.OnAdd(d.Object ) 
} 
case cache.Deleted: 
if err := 


clientState.Delete(d.Object); err != nil { 
return err 


} 
h.OnDelete(d.Object ) 


j 


return nil 
上 
} 


return clientState, New(cfg) 


Æ ERREF, Ilw (ListerWatcher) 用 来 获取 和 监测 资源 对 象 的 
变化 ， 而 fifo 则 是 一 个 DeltaFIFO 的 Queue， 用 来 存放 变化 的 资源 (需要 


同步 的 资源 ) 。 当 Controller 框 架 发 现 有 变化 的 资源 需要 处 理 时 ， 就 会 
将 新 资源 与 本 地 缓存 clientState 中 的 资源 进行 对 比 ， 然 后 调用 相应 的 资 
源 处 理 函 数 ResourceEventHandler 的 方法 ， 完 成 具体 的 处 理 逻 辑 。 下 面 
是 针对 RC 的 ResourceEventHandler 的 具体 实现 : 


framework.ResourceEventHandlerFuncs{ 
AddFunc: rm.enqueueController, 
UpdateFunc: func(old, cur interface{}) { 
oldRC := old. 


(*api.ReplicationController) 


(*api.ReplicationController) 
if oldRC.Status.Replicas != 
curRC.Status.Replicas { 
glog.V(4).Infof("Observed updated 
replica count for rc: 96V , 96d - 296d" , curRC.Name, 
oldRC.Status.Replicas, curRC.Status.Replicas) 
} 


rm.enqueueController(cur) 


ty 


DeleteFunc: rm.enqueueController, 


在 上 述 源 码 中 ， 我 们 看 到 当 RC 里 Pod 的 副本 数量 属性 发 生变 化 以 
后 ，ResourceEventHandler 就 将 此 RC 放 入 ReplicationManager 的 queue 队 
列 中 等 竺 处理， 为 什么 没有 在 这 个 handler 函 数 中 直接 处 理 而 是 移 放 入 
队列 再 异步 处 理 呢 ? 最 主要 的 一 个 原因 是 Pod 副 本 创建 的 过 程 比 较 耗 


时 。Controller 框 架 把 需要 同步 的 RC 对 象 放 入 queue 以 后 ， 接 下 来 是 谁 
在 “消费 ”这 个 队列 昵 ? 答案 就 在 ReplicationManager 的 Run () 方法 
FH. 


func (rm *ReplicationManager) Run(workers int, stopCh 

«-chan struct{}) { 

defer util.HandleCrash() 

go rm.rcController.Run(stopCh) 

go rm.podController.Run(stopCh) 

for i := 0; i < workers; i++ { 

go util.Until(rm.worker, time.Second, stopCh) 

} 

«-stopCh 

glog.Infof("Shutting down RC Manager") 


rm.queue.ShutDown( ) 


Ext: fe 83 B tA Bi rcController 5 podControlleriX Pj ^ Controller , 
启动 之 后 ， 这 两 个 Controller 就 分 别 开 始 拉 取 RC 与 Pod 的 变动 信息 ， 随 
后 又 启动 N 个 协 程 并 发 处 理 RC 的 队列 ， 其 中 func Until (ffunc ()， 
period time.Duration, stopCh<-chan struct{}) 方法 的 逻辑 是 按照 指定 的 
JE SH period £7 7; Af ° F Ifi Æ ReplicationManager H^] worker 77 7X H^] YE 
码 ， 负 责 从 RC 队 列 中 拉 取 RC 并 调用 rm 的 SyncHandler 方 法 完成 具体 处 
理 : 


func (rm *ReplicationManager) worker() { 


for ( 


func() { 
key, quit := rm.queue.Get() 
if quit { 
return 
} 
defer rm.queue.Done(key) 
err := rm.syncHandler (key. (string) ) 
if err != nil { 
glog.Errorf("Error syncing replication 
controller: %v", err) 
} 
}() 


从 ReplicationManager 的 构造 函数 中 我 们 得 知 : syncHandler 在 这 里 
其 实 是 func (rm*ReplicationManager) syncReplicationController (key 


string) 方法 。 下 面 是 该 方法 的 源码 : 


func (rm *ReplicationManager ) 
syncReplicationController(key string) error { 
startTime := time.Now() 
defer func() { 
glog.V(4).Infof("Finished syncing controller 


%q (%V)", key, time.Now().Sub(startTime)) 
}() 


obj, exists, err = 
rm.controllerStore.Store.GetByKey(key) 
if !exists ( 
glog.Infof("Replication Controller has been 
deleted %v", key) 
rm.expectations.DeleteExpectations(key) 
return nil 
} 
if err != nil { 
glog.Infof("Unable to retrieve rc %v from 
store: %v", key, err) 
rm. queue.Add( key) 
return err 
} 
controller := *obj.(*api.ReplicationController ) 
if !rm.podStoreSynced() { 
// Sleep so we give the pod reflector 
goroutine a chance to run. 
time.Sleep(PodStoreSyncedPollPeriod) 
glog.Infof("Waiting for pods controller to 
sync, requeuing rc %v", controller.Name) 
rm.enqueueController(&controller) 


return nil 


rcNeedsSync :二 


rm.expectations.SatisfiedExpectations(&controller) 


podList, err := 
rm.podStore.Pods(controller.Namespace).List(labels.Set(cont 
roller.Spec.Selector).AsSelector()) 
if err != nil { 
glog.Errorf("Error getting pods for rc %q: 
%v", key, err) 
rm.queue.Add(key) 


return err 


filteredPods :- filterActivePods(podList.Items) 
if rcNeedsSync ( 


rm.manageReplicas(filteredPods, &controller) 


if err :二 
updateReplicaCount(rm.kubeClient.ReplicationControllers(con 
troller.Namespace), controller, len(filteredPods)); err != 
nil { 

rm.enqueueController(&controller) 


j 


return nil 


在 上 述 代码 里 有 一 个 重要 的 流 控 变量 rcNeedsSync。 为 了 限 流 ， 在 
RC 同步 逻辑 的 过 程 中 ， 一 个 RC 每 次 最 多 执行 N 个 Pod 的 创建 、 删 除 ， 
如 果 某 个 RC 的 同步 过 程 涉及 的 Pod 副 本 数量 超过 burstReplicas 这 个 国 


值 ， 束 会 采用 RCExpectations 机 制 进行 限 流 。RCExpectations 对 和 象 可 以 
理解 为 一 个 简单 的 规则 : 即 在 限定 的 时 间 内 执行 N 次 操作 ， 每 次 操作 
都 使 计数 器 减 一 ， 计 数 器 为 零 表示 N 个 操作 已 经 完成 ， 可 以 进行 下 一 
批 次 的 操作 了 ° 


Kubemetes 为 什么 会 设计 这 样 一 个 流程 控制 机 制 ? 其 实 答案 很 简 
单一 一 为 了 公平 。 因 为 谷歌 的 开发 Kubernetes 的 资深 大 牛 们 早已 预见 
到 某 个 RC 的 Pod 副 本 一 次 扩容 至 100 倍 的 极端 情况 可 能 真实 发 生 ， 如 果 
没有 流 控 机 制 ， 则 这 个 巨 无 堪 的 RC 同步 操作 会 导致 其 他 众多 “散户 ”月 
im! 这 绝对 不 是 谷歌 的 理念 。 


接着 看 上 述 代 人 码 里 所 调用 的 ReplicationManager 的 manageReplicas 
方法 ， 这 是 RC 同步 的 具体 逻辑 实现 ， 此 方法 采用 了 并 发 调用 的 方式 执 
行 批 量 的 Pod 副 本 操作 任务 ， 相 关 代 码 如 下 : 


wait := sync.WaitGroup{} 
wait .Add(diff) 
glog.V(2).Infof("Too few %q/%q replicas, need 
%d, creating %d", controller.Namespace, controller.Name, 
controller.Spec.Replicas, diff) 
for i := 0; i < diff; i++ { 
go func() { 
defer wait.Done() 
if err := 
rm.podControl.createReplica(controller.Namespace, 
controller); err != nil { 


glog.V(2).Infof("Failed creation, 


decrementing expectations for controller %q/%q", 


controller .Namespace, controller .Name) 


rm.expectations.CreationObserved(controller) 


util.HandleError(err) 


3() 
j 


wait.Wait() 


BRAM, RNA EP SU tl Ë Pod MAN BRIERE 
PodControl.createReplica () 方法 里 ， 而 此 方法 的 具体 实现 方法 则 是 
RealPodControl.createReplica () ， 位 于 controller_utils.go 里 。 通 过 分 析 
该 方法 ， 我 们 可 以 知道 创建 Pod 副 本 的 过 程 就 是 创建 一 个 Pod 资 源 对 
象 ， 并 把 RC 中 定义 的 Pod 模 板 赋 值 给 该 Pod 对 象 ， 并 且 Pod 的 名 字 用 RC 
的 名 字 做 前 级 ， 最 后 调用 Kubernetes Client 将 Pod 对 象 通过 Kubernetes 
API Server 写 入 后 端的 etcd 存 储 中 。 


在 本 节 最 后 ， 我 们 来 分 析 一 下 Controller 框 架 中 如 何 实现 资源 对 象 
的 查询 和 监听 逻辑 并 且 在 资源 发 生变 动 时 回调 Controller Config 对 象 中 
的 Process 方 法 : func (obj interface{}) ， 最 终 完 成 整个 Controller 框 架 
的 闭环 过 程 。 


首先 ， 在 Controller 框 架 中 构建 了 Reflector 对 和 象 以 实现 资源 对 象 的 
查询 和 监 昕 逻辑， 它 的 源码 位 于 pkg/client/cache/reflector.go 中 ， 我 们 看 
一 下 这 个 对 象 的 数据 结构 残 基 本 明日 了 其 工作 原理 ; 


// Reflector watches a specified resource and causes 
all changes to be reflected in the given store. 
type Reflector struct { 


// The type of object we expect to place in the 


store. 
expectedType reflect.Type 
// The destination to sync up with the watch 
source 
store Store 
// listerWatcher is used to perform lists and 
watches. 
listerWatcher ListerWatcher 
// period controls timing between one watch ending 
and 


// the beginning of the next one. 
period time.Duration 
resyncPeriod time.Duration 
// lastSyncResourceVersion is the resource version 
token last 
// observed when doing a sync with the underlying 
store 
// it is thread safe, but not synchronized with 
the underlying store 
lastSyncResourceVersion string 
// lastSyncResourceVersionMutex guards read/write 


access to lastSyncResourceVersion 


lastSyncResourceVersionMutex sync.RWMutex 


核心 思路 就 是 通 ee KYR U 听 资 源 的 变 
化 ， 然 后 存储 到 store 中 。 这 里 你 可 能 有 个 疑问 ， 这 个 store 完 竟 是 哪个 
对 象 ? 是 ReplicationManager 里 HY controllerStore 还 是 
framework.NewInformer () 方法 里 创建 的 fifo 队 列 ? 


下 面 的 两 段 来 自 pkg/controller/framework/controller.go 的 代码 会 告 
诉 我 们 答案 。 


首先 是 来 自 Controller 的 run 方 法 func ( c*Controller ) Run 
(stopCh<-chan struct{}) 的 代码 片段 : 


r := cache.NewReflector ( 
c.config.ListerWatcher, 
c.config.ObjectType, 
c.config.Queue, 


c.config.FullResyncPeriod, 


9K Ja xe X E] Controller ÀJ NewInformer Ù 14 func NewInformer (lw 
cache.ListerWatcher  , objType — runtime.Object  , resyncPeriod 


time.Duration , h ResourceEventHandler , ) ( cache.Store , 


*Controller) 中 的 代码 片段 : 


cfg := &Config{ 


Queue: fifo, 


ListerWatcher: lw, 
ObjectType: objType, 
FullResyncPeriod: resyncPeriod, 


RetryOnError: false, 


4j Br Ew iS. AT] & XE Reflector P AY) store 其 实 是 引用 
Controller.Config 里 的 Queue 属 性 ， 即 fifo 队 列 ， 而 非 ReplicationManager 
里 的 controllerStore。 我 们 费 了 这 么 大 的 劲 ， 才 和 弄 明 日 这 个 简单 的 问 
题 ， 这 告诉 我 们 一 个 事实 : 编程 中 有 民 好 的 命名 规则 很 重要 。 


下 面 这 段 代码 是 Controller 从 队列 Queue 中 拉 取 资源 对 象 并 且 交 给 
Controller.Config 对 象 中 的 Process 方 法 func (obj interface{}) 进行 处 
理 ， 从 而 最 终 完 成 了 整个 Controller 框 染 的 闭环 过 程 。 


func (c *Controller) processLoop() { 


for { 
obj := c.config.Queue.Pop( ) 
err := c.config.Process(obj ) 
if err != nil { 
if c.config.RetryOnError { 
// This is the safe way to re-enqueue. 
c.config.Queue.AddIfNotPresent (obj ) 
} 
} 
} 


至 于 上 述 过 程 的 调用 则 是 在 Controller 启 动 (Run 方 法 ) 的 最 后 一 
步 里 ，Controller 框 以 定时 每 秒 调用 一 次 上 述 函 数 ， 代 码 如 下 : 


util.Until(c.processLoop, time.Second, stopCh) 


最 后 ， 给 读者 留 一 个 源码 解读 的 问题 ， 即 ReplicationManager 里 除 
了 RC Controller， 义 构造 了 一 个 用 于 Pod 有 的 Controller， 它 的 逻辑 具体 是 
怎样 实现 的 ? 它 与 RC Controller 是 怎样 交互 的 ? 


6.3.3 ”设计 总 结 


相对 于 之 前 的 Kubernetes API Server 设计 来 说 ， Kubernetes 
Controller Server 的 设计 没有 那么 复杂 ， 而 且 精 彩 依旧 。 不 愧 是 大 师 的 
作品 ，ControllerFramework 精 巧 细致 的 设计 使 得 整个 进程 中 各 种 资源 
对 象 的 同步 逻辑 在 代码 实现 方面 保持 了 高 度 一 致 性 与 简捷 性 。 此 外 ， 
在 关键 资源 RC (ReplicationController) 的 同步 逻辑 中 所 采用 的 流 控 机 
制 也 人 简单、 高 效 。 


AX $ Fk fl] £F Xf Kubernetes Controller Server 中 的 精华 部 分 一 一 
Controller Framework Hy ix iL fü — ^^ 5k X8 4j Dr 9» Bb jb, 
framework.Controller 内 部 维护 一 个 Config 对 象 ， 保 留 了 一 个 标准 的 消 
息 、 事 件 分 发 系统 的 三 要 素 。 


。 人 和牛 产 者 : cache.ListerWatch ° 
e 队列 : cache.cacheStore (Queue) ° 
dH. ® 者 : A FA 调 wm XX 来 模 拟 


(framework.ResourcceEventHandlerFuncs) 。 


由 于 生产 者 的 逻辑 比较 复杂 ， 在 这 个 系统 中 也 有 其 特殊 性 ， 即 拉 
取 资 源 并 监控 资源 的 变化 ， 由 此 产生 了 真正 的 待 处 理 任务 ， 所 以 又 设 
计 了 一 个 ListerWatcher 接 口 ， 将 底层 的 复杂 逻辑 “框架 化 ”"， 放 入 
cache.Reflector 中 ， 使 用 者 只 要 简单 地 实现 ListerWatcher 接 口 的 ListFunc 
与 WatchFunc 即 可。 另外 ，cache.Reflector 也 是 独立 于 Controller 
Framework 的 一 个 组 件 ， 隶 属于 cache 包 ， 它 的 功能 是 将 任意 资源 对 象 


拉 取 到 本 地 缓存 中 并 监控 资源 的 变化 ， 保 持 本 地 缓存 的 同步 ， 其 目标 
是 减轻 对 Kubernetes API Server 的 请 求 压 力 。 


6.4 给 出 了 ControllerFramework 的 整体 架构 设计 图 。 


通过 Kubemetes Rest Client 拉 取 并 监控 
资源 的 变化 ， 己 发 生 改变 的 资源 放 入 
FIFO 队列 中 等 待 处 理 


cacheReflector N= 3» cache.ListerWatcher 


* 


API Server 


m 


创建 Refelctor 并 周期 性 调用 | > 
; - — 1——31| client.Client 

ListAndWatch 方法 | 

framework.Controller Y 


cache.Store 


周期 性 调用 Handler 


方法 处 理 队 列 


framework ResourceEventHandlerFuncs 


6.4 Controller Framework 的 整体 架构 设计 


Kubernetes Controller Server 中 所 有 涉及 同步 的 资源 都 采用 了 
Controller Framework 框 架 来 进行 驱动 ， 图 6.5 给 出 了 整体 设计 示意 图 。 


从 图 6.5 可 以 看 出 ， 除 了 Node、Route、CloudService 这 三 个 资源 依 
赖 于 Kubernetes 所 处 的 云 计算 环境 ， 只 能 通过 CloudProvider 接 口 所 提供 
的 API 来 完成 资源 同步 ， 其 他 资源 都 采用 了 Controller Framework 框 以 
来 进行 资源 同步 。 图 中 的 虚线 箭头 表示 针对 目标 资源 创建 了 一 个 
framework.Controller 对 象 ， 其 中 的 某 些 资源 如 RC、PV、Tokens 的 同步 
过 程 需 要 获取 并 监听 其 他 与 之 相关 联 的 资源 对 象 。 这 里 只 


ResourceQuota 资 源 比较 另类 ， 它 没有 采用 Controller Framework， 一 个 


E 因 是 ResourceQuota 涉 及 很 多 资源 对 象 ， 不 大 好 应 用 
framework.Controller， 另 外 一 个 原因 可 能 是 写 ResourceQuotaManager 的 
大 牛 拥 有 比较 浪漫 的 情怀 ， 看 看 下 面 这 段 Kubernetes 中 最 优美 的 代码 
m. 


func (rm  *ResourceQuotaManager)  Run(period 
time.Duration) ( 
rm.syncTime - time.Tick(period) 
go util.Forever(func() { rm.synchronize() }, 
period) 


j 


核心 代码 翻译 过 来 就 是 这 个 意思 : Muir b T See Ee, 
SRR RI ! 


[6.5 Kubernetes Controller Server 整 体 设计 示意 图 


6.4 ”kube-scheduler 进 程 产 码 分 析 


Kubernetes Scheduler Server 是 由 kube-scheduler 进 程 实现 的 ， 它 运 
行 在 Kubernetes 的 管理 节点 一 Master 上 并 主要 负责 完成 从 Pod 到 Node 
的 调度 过 程 。Kubernetes Scheduler Server 跟 踪 Kubernetes 集 群 中 所 有 
Node 的 资源 利用 情况 ， 并 采取 合适 的 调度 策略 ， 确 保 调 度 的 均衡 性 ， 
避免 集群 中 的 某 些 节点 “过 载 ?。 从 某 种 意义 上 来 说 ，Kubernetes 
Scheduler Server 也 是 Kubernetes 集 群 的 “大 脑 ”。 


谷歌 作为 公有 云 的 重要 供应 商 ， 积 累 了 很 多 经 验 并 且 了 解 客户 的 
需求 。 在 谷歌 看 来 ， 客 户 并 不 真正 关心 他 们 的 服务 完 竟 运行 在 哪 台 机 
器 上 ， 他 们 最 关心 服务 的 可 靠 性 ， 和 希望 发 生 故 障 后 能 目 动 恢复。 遵循 
这 一 指导 思想 ，Kubernetes Scheduler Server 实 现 了 “完全 市 场 经 济 ” 的 
调度 原则 并 彻 的 抛弃 了 传统 意义 上 的 “计划 经 济 ”。 


下 面 我 们 分 别 对 其 局 动 过程 、 关 键 代码 分 析 及 设计 总 结 等 方面 进 
行 深入 分 析 和 讲解 。 


6.4.1 ”进程 局 动 过 程 


kube-scheduler 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/plugin/cmd/kube- 


scheduler/scheduler.go? 
入 口 main () 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS( runtime .NumCPU( ) ) 
S := app.NewSchedulerServer ( ) 
s.AddFlags(pflag.CommandLine) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 


s.Run(pflag.CommandLine.Args()) 


对 上 述 代 码 的 风格 和 逻辑 我 们 再 熟悉 不 过 了 : 创建 一 个 
SchedulerServer 对 象 ， 将 命令 行 参 数 传 入 ， 并 且 进 入 SchedulerServer 的 
Run iE, AREA RE ° 


按照 惯例 ， 我 们 首先 看 看 SchedulerServer 的 数据 结构 
(app/servergo) ， 下 面 是 其 定义 : 


type SchedulerServer struct { 
Port int 
Address util.IP 
AlgorithmProvider string 
PolicyConfigFile string 


EnableProfiling bool 


Master string 
Kubeconfig string 
} 
这 里 的 关键 属性 有 以 下 两 个 。 
。 AlgorithmProvider : 对 应 参数 algorithm-provider , 是 


AlgorithmProviderConfig 的 名 称 。 
e PolicyConfigFile: 用 来 加 载 调度 策略 文件 。 


从 代码 上 来 看 这 两 个 参数 的 作用 其 实 是 一 样 的 ， 都 征 加 载 一 组 调 
度 规 则 ， 这 组 调度 规则 要 人 么 在 程序 里 定义 为 一 个 
AlgorithmProviderConfig， 要 么 保存 到 文件 中 。 下 面 的 源码 清楚 地 解释 
了 这 个 过 程 : 


func (s *SchedulerServer) createConfig(configFactory 
*factory.ConfigFactory) (*scheduler.Config, error) { 
var policy schedulerapi.Policy 


var configData []byte 


if _, err := os.Stat(s.PolicyConfigFile); err == 
nil { 
configData, err = 
ioutil.ReadFile(s.PolicyConfigFile) 
if err != nil { 
return nil, fmt.Errorf("Unable to read 
policy config: %v", err) 
} 
err = 
latestschedulerapi.Codec.DecodeInto(configData, &policy) 
if err != nil { 
return nil, fmt.Errorf("Invalid 


configuration: %v", err) 


j 


return configFactory.CreateFromConfig(policy) 


// if the config file isn't provided, use the 
specified (or default) provider 
// check of algorithm provider is registered and 
fail fast 
a err = 
factory.GetAlgorithmProvider(s.AlgorithmProvider ) 
if err != nil { 


return nil, err 


return 
configFactory.CreateFromProvider(s.AlgorithmProvider ) 


j 


创建 了 SchedulerServer 结 构 体 实例 后 ， 调 用 此 实例 的 方法 func 
(stAPIServer) Run (_[]string) ， 进 入 关键 流程 。 首 先 ， 创 建 一 个 
Rest Client 对 象 用 于 访问 Kubernetes API Server 提 供 的 API 服 务 : 


kubeClient, err := client.New(kubeconfig) 
if err != nil { 
glog.Fatalf("Invalid API configuration: %v", 


err) 


随后 ， 创 建 一 个 HITP Server 以 提供 必要 的 性 能 分 析 (Performance 
Profile) 和 性 能 指标 度量 (Metrics) 的 Rest 服 务 : 


go func() { 
mux := http.NewServeMux() 
healthz.InstallHandler (mux) 
if s.EnableProfiling { 
mux.HandleFunc("/debug/pprof/", 
pprof.Index) 
mux.HandleFunc("/debug/pprof/profile", 
pprof.Profile) 


mux.HandleFunc("/debug/pprof/symbol", 
pprof.Symbol) 
} 


mux.Handle("/metrics", prometheus.Handler()) 


server :- &http.Server( 
Addr: 
net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), 
Handler: mux, 
} 


glog.Fatal(server.ListenAndServe()) 


3() 


接 下 来 ， 启 动 程序 构造 了 ConfigFactory， 这 个 结构 体 包括 了 创建 


一 个 Scheduler 所 需 的 必要 属性 


PodQueue: 需要 调度 的 Pod 队 列 。 

BindPodsRateLimiter: 调度 过 程 中 限制 Pod 绑 定 速度 的 限 速 器 
modeler: 这 是 用 于 优化 Pod 调 度 过 程 而 设计 的 一 个 特殊 对 象 ， 用 
于 “预测 未 来 ”。 一 个 Pod 被 计划 调度 到 机 器 A 的 事实 被 称 为 
assumed 调 度 ， 即 假定 调度 ， 这 些 调度 安排 被 保存 到 特定 队列 里 ， 
此 时 调度 过 程 是 能 看 到 这 个 预 安 排 的 ， 因 而 会 影响 到 其 他 Pod 的 
调度 。 

PodLister: 负责 拉 取 已 经 调度 过 的 ， 以 及 被 假定 调度 过 的 Pod 列 
Fo 

NodeLister: 负责 拉 取 Node 忆 点 (Minion) 列表 ° 

ServiceLister: 负责 拉 取 Kubernetes 服 务 列表 。 


e ScheduledPodLister ` scheduledPodPopulator: Controller f= 22 £1] £& 
过 程 中 返回 的 Store 对 象 与 controller 对 象 ， 负 责 定期 从 Kubernetes 
API Server 上 拉 取 已 经 调度 好 的 Pod 列 表 ， 并 将 这 些 Pod 从 modeler 
的 假定 调度 过 的 队列 中 删除 。 


在 构 造 ConfigFactory 的 7j 法 factoryNewConfigFactory 
(kubeClient) 中 ， 我 们 看 到 下 面 这 段 代 码 : 


c.ScheduledPodLister.Store, c.scheduledPodPopulator = 
framework .NewInformer ( 
c.createAssignedPodLw(), 
&api.Pod(), 
0, 
framework.ResourceEventHandlerFuncs{ 
AddFunc: func(obj interface{}) { 
if pod, ok := obj.(*api.Pod); ok { 
c.modeler.LockedAction(func() { 
c.modeler.ForgetPod(pod) 
3) 


ty 
DeleteFunc: func(obj interface{}) { 
c.modeler.LockedAction(func() { 
switch t := obj.(type) { 
case *api.Pod: 
c.modeler.ForgetPod(t) 


case 


cache.DeletedFinalStateUnknown: 


c.modeler.ForgetPodByKey(t.Key) 
} 
}) 
3 
ty 


这 里 沿用 了 之 前 看 到 的 controller framework AY E $2 , E xk 
Controller 实 例 所 做 的 事情 是 获取 并 监听 已 经 调度 的 Pod 列 表 ， 并 将 这 
些 Pod 列 表 从 modeler 中 的 “assumed” 队 列 中 删除 。 


接 下 来 ， 局 动 进程 用 上 述 创 建 好 的 ConfigFactory 对 象 作为 参数 来 
调用 SchdulerServer 的 createConfig 方 法 ， 创 建 一 个 SchedulerConfig 对 
象 ， 而 此 段 代 码 的 关键 逻辑 则 集中 在 ConfigFactory 的 CreateFromKeys 
这 个 函数 里 ， 其 主要 步骤 如 下 。 


(1) 创建 一 个 与 Pod 相 关 的 Reflector 对 象 并 定期 执行 ， 该 Reflector 

负责 查询 并 监测 等 待 调度 的 Pod 列 表 ， 即 还 没有 分 配 主机 的 Pod 

(Unsigned Pod) ， 然 后 把 它们 放 入 ConfigFactory 的 PodQueue 中 等 待 

调度 。 相 关 代 码 为 : cache.NewReflector (f.createUnassignedPodLW 
() , &api.Pod(), f.PodQueue, 0) .RunUntil (f.StopEverything) ° 


(2) 启动 ConfigFactory 的 ScheduledPodPopulator Controller $& , 
负责 定期 从 Kubernetes API Server 上 拉 取 已 经 调度 好 的 Pod 列 表 ， 并 将 
这 些 Pod 从 modeler 中 的 假定 (assumed) 调度 过 的 队列 中 删除 。 相 关 代 
码 为 : go fscheduledPodPopulatorRun (f.StopEverything) ° 


(3) 创建 一 个 Node 相 关 的 Reflector 对 象 并 定期 执行 ， 该 Reflector 
人 负责 查询 并 监测 可 用 的 Node 列 表 (可 用 意味 着 Node 的 
spec.unschedulable 属 性 为 false) ， 这 些 Node 被 放 入 ConfigFactory 的 
NodeListerStore 里 。 相关 代码 为 : cacheNewReflector 
( f.createMinionLW ( ) , &api.Node{} , f.NodeLister.Store , 
0) .RunUntil (f.StopEverything) 。 


(4) 创建 一 个 Service 相 关 的 Reflector 对 象 并 定期 执行 ， 该 
Reflector 人 负责 查询 并 监测 已 定义 的 Service 列 表 ， 并 放 入 ConfigFactory 
的 ServiceListerStore 里 。 这 个 过 程 的 目的 是 Scheduler 需 要 知道 一 个 
Service 当 前 所 创建 的 所 有 Pod， 以 便 能 正确 地 进行 调度 。 相 关 代 码 
Jj: cache.NewReflector (f.createServiceLW () , &api.Service{}, 


f.ServiceLister.Store, 0) .RunUntil (f.StopEverything) ° 


(5) 创建 一 个 实现 了 algorithm.ScheduleAlgorithm 接口 的 对 象 
genericScheduler, ， 它 负责 完成 从 Pod 到 Node 的 具体 调度 工作 ， 调 度 完 
EX HJ Pod Ùx A ConfigFactory 的 PodLister 里 。 相 关 人 代码 为 algo: 
=scheduler.NewGenericScheduler ( predicateFuncs , priorityConfigs , 
f.PodLister, r) ° 


(6) 最 后 一 步 ， 使 用 之 前 的 这 些 信 息 创 建 Scheduler.Config 对 象 并 
返回 。 


从 上 面 的 分 析 我 们 看 出 ， 其 实在 创建 SchedulerConfig 的 过 程 中 已 
经 完成 了 Kubernetes Scheduler Server 进 程 中 的 很 多 局 动工 作 ， 于 是 整 
个 进程 的 启动 过 程 的 最 后 一 步 答 单 明 了 : 使 用 刚刚 创建 好 的 Config 对 
象 来 构造 一 个 Scheduler 对 象 并 局 动 运行 。 即 下 面 的 两 行 代码 ; 


sched := scheduler .New(config) 


sched. Run() 


而 Scheduler 的 Run 方 法 就 是 不 停 地 执行 ScheduleOne 方 法 : 


go util.Until(s.scheduleOne, 0, 


s.config.StopEverything ) 


scheduleOne 方 法 的 逻辑 也 比较 清晰 ， 即 获取 下 一 个 待 调度 的 
Pod， 然 后 交 给 genericScheduler 进 行 调度 〈 完 成 Pod 到 某 个 Node 的 绑 定 
WE) ， 调 度 成 功 以 后 通知 Modeler。 这 个 过 程 同 时 增加 了 限 流 和 性 能 
指标 的 逻辑 。 


6.4.2 ”关键 代码 分 析 


在 6.4.1 节 对 kube-scheduler 进 程 的 启动 过 程 进行 详细 分 析 后 ， 我 们 
HH EI f Kubernetes Scheduler Server 的 工作 流程 ， 但 由 于 代码 中 涉 
及 多 个 Pod 队 列 和 Pod 状 态 切 换 逻 辑 ， 因 此 这 里 有 必要 对 这 个 问题 进行 
详细 分 析 ， 以 弄 清 在 整个 调度 过 程 中 Pod 的 “来 龙 去 脉 ”。 首 移 ， 我 们 知 
道 ConfigFactory 里 的 PodQueue 是 “得 调度 的 Pod 队 列 *， 这 个 过 程 是 通过 
无 限 循环 执行 一 个 Reflector 来 从 Kubernetes API Server 上 获取 得 调度 的 
Pod 列 表 并 填充 到 队列 中 实现 的 ， 因 为 Reflector 框 架 已 经 实现 了 通用 的 
代码 ， 所 以 到 了 Kubernetes Scheduler Server 这 里 ， 通 过 一 行 代 码 就 能 
完成 这 个 复杂 的 过 程 : 


cache.NewReflector(f.createUnassignedPodLW(), 


&api.Pod(), f.PodQueue, 0).RunUntil(f.StopEverything) 


上 述 代 码 中 的 createUnassignedPodLW 是 查询 和 监测 spec.nodeName 

为 至 的 Pod 列 表 ， 上 此外， 我们 注意 到 schedulerConfig 里 提供 了 NextPod 
这 个 函数 指针 来 从 上 述 队 列 中 消费 一 个 元 素 ， 下 面 是 相关 代码 片段 
(来 目 ConfigFactory 的 CreateFromKeys 方 法 中 创建 shedulerConfig 的 代 


fg) : 


NextPod: func() *api.Pod { 
pod := f.PodQueue.Pop().(*api.Pod) 
glog.V(2).Infof("About to try and schedule 


pod %v", pod.Name) 


return pod 


ty 


然后 ， 这 个 PodQueue 是 怎样 被 消费 的 呢 ? 残 在 之 前 提 到 的 
SchedulerscheduleOne 的 方法 里 ， 每 次 调用 NextPod 方 法 会 获取 一 个 可 
用 的 Pod， 然 后 交 给 genericScheduler 进 行 调 度 ， 下 面 是 相关 代码 片段 

(省 略 了 其 他 代码 ) : 


pod := s.config.NextPod() 
if s.config.BindPodsRateLimiter != nil { 


s.config.BindPodsRateLimiter.Accept() 


dest, err :=  s.config.Algorithm.Schedule(pod, 


s.config.MinionLister ) 


genericScheduler.Schedule 方 法 只 是 给 出 该 Pod 调 度 到 的 目标 Node， 
如 果 调 度 成 功 ， 则 设置 该 Pod 的 spec.nodeName 为 日 标 Node， 然 后 通过 
HTTP Rest 调 用 写 入 Kubernetes API Server 里 完成 Pod 的 Binding 操 作 ， 
最 后 通知 ConfigFactory 的 modeler (具体 实例 对 应 
scheduler.SimpleModeler) ， 将 此 Pod 放 入 Assumed Pod 队 列 ， 下 面 是 相 
KARIA Ex: 


s.config.Modeler.LockedAction(func() { 
bindingStart := time.Now() 


err := s.config.Binder.Bind(b) 


metrics.BindingLatency.Observe(metrics.SincelnMicroseconds( 


bindingStart) ) 
s.config.Recorder.Eventf(pod, "scheduled", 
"Successfully assigned %v to %v", pod.Name, dest) 
// tell the model to assume that this 
binding took effect. 
assumed :- *pod 
assumed.Spec.NodeName - dest 


s.config.Modeler.AssumePod(&assumed) 


}) 


当 Pod 执 行 Bind 操 作成 功 以 后 ，Kubernetes API Server 上 Pod 已 经 满 
足 “ 已 调度 ”的 条 件 ， 因 为 spec.nodeName 已 经 被 设置 为 目标 Node 地 址 ， 
此 时 ConfigFactory 的 scheduledPodPopulator 这 个 Controller 就 会 监听 到 此 
变化 ， 将 此 Pod 从 modeler 中 的 Assumed 队 列 中 删除 ， 下 面 是 相关 代码 
Fr Ex: 


framework.ResourceEventHandlerFuncs{ 
AddFunc: func(obj interface{}) { 
if pod, ok := obj. 
(*api.Pod); ok ( 


c.modeler.LockedAction(func() { 


c.modeler.ForgetPod(pod) 
3) 


谷歌 的 大 神 在 源码 中 说 明 Modeler 的 存在 是 为 了 调度 的 优化 ， 那 么 
这 个 优化 具体 体现 在 哪里 昵 ? 由 于 Rest Watch API 存 在 延 时 ， 当 前 已 经 
调度 好 的 Pod 很 可 能 还 未 被 通知 给 Scheduler ， 于 是 大 神灵 光一 内 : 为 
每 个 刚刚 调度 完成 的 Pod 发 放 一 个 “暂住证 ”， 安 排 “ 暂 
住 ”到 “Assumed” 队 列 里 ， 然 后 设计 一 个 获取 当前 “已 调度 ”的 Pod 队 列 的 
新 方法 ， 该 方法 合并 Assumed 队 列 与 Watch 缓存 队列 ， 这 样 一 来 ， 束 得 
到 了 最 佳 答 案 。 如 果 你 打算 看 看 这 段 代 码 ， 那 么 它 束 在 SimpleModeler 
的 listPods 方法 里 ， 至 此， 你 若 也 完全 明和 白 了 了 
c.PodLister=modeler.PodLister () XAJ FEI REARS, PARE 
你 ， 你 离 大 神 的 距离 又 缩短 了 一 个 厘米 。 


接 下 来 ， 我 们 深入 分 析 Pod 调 度 中 所 用 到 的 流 控 技术 ， 绎 起 于 下 
面 这 上 段 代 码 : 


if s.config.BindPodsRateLimiter != nil { 
s.config.BindPodsRateLimiter .Accept() 


j 


上 述 代 码 中 的 BindPodsRateLimiter 采 用 了 开源 项 目 juju 的 一 个 子 项 
目 ratelimit， 项 目地 址 为 https://github.conyjuju/ratelimit， 它 实现 了 一 个 
高 效 的 基于 经 典 令 牌 桶 〈Token Bucket) 的 流 控 算法 。 如 图 6.6 所 示 是 
经 典 令 牌 桶 流 控 算法 的 原理 示意 图 。 


生产 者 线程 
r tokens/sec 


bucket holds up to 
b tokens 


do work 


EE 
消费 者 线程 wait 


Al6.6 令 牌 桶 流 控 算法 示意 图 


简单 地 说 ， 控 制 线程 以 固定 速率 向 一 个 固定 容量 的 桶 (Bucket) 
中 投放 令 牌 (Token) ， 消 费 者 线程 则 等 待 并 获取 到 一 个 令 牌 后 才能 继 
续 接 下 来 的 任务 ， 人 否则 需要 等 竺 可 用 令 牌 的 到 来 。 具 体 说 来 ， 假 如 用 
户 配置 的 平均 限 流 速率 为 r， 则 每 隔 1 秒 融会 有 一 个 令 牌 被 加 入 桶 中 ， 
而 令 牌 桶 最 多 可 以 存储 b 个 令 牌 ， 如 有 果 令 牌 到 达 时 令 牌 桶 已 经 满 了 ， 那 
么 这 个 令 牌 会 被 丢弃 。 从 长 期 运行 结 采 来 看 ， 消 费 痢 的 处 理 速率 被 限 
制 成 音量 r。 令 牌 桶 流 控 算法 除了 能 够 限制 平均 处 理 速 度 ， 还 允许 某 种 
程度 的 突 发 速率 o 


juju 的 ratelimit 模 块 通过 下 面 的 API 提 供 了 构造 一 个 令 牌 桶 的 简单 
做 法 ， 其 中 ，rate 参 数 表 示 每 秒 填充 到 桶 里 的 令 脾 数量 ，capacity 则 是 
桶 的 容量 : 


func NewBucketWithRate(rate float64, capacity int64) 


*Bucket 


我 们 回头 再 看 看 Kubernetes SchedulerServer + BindPodsRateLimiter 

的 赋值 代码 : c.BindPodsRateLimiter=util. NewTokenBucketRateLimiter 

(BindPodsQps , BindPodsBurst) ， 跟 踪 进 去 ， 发 现 它 就 是 调用 了 刚 

Zr Ar $e 21] AY juju ER Ži limiter: =ratelimit.NewBucketWithRate ( float64 

(qps) , int64 (burst) ) ， 其 中 qps 目 前 为 常量 15， 而 burst 为 20， 目 

前 在 Kubernetes 1.0 和 版 本 中 还 没有 提供 命令 行 参数 来 配置 此 变量 ， 会 在 
未 来 的 版 本 中 实现 。 


最 后 ， 我 们 一 起 深入 分 析 Kubernetes Scheduer Server 中 关于 Pod 调 
度 的 细节 。 首 先 ， 我 们 需要 理解 启动 过 程 中 SchedulerServer 加 载 调度 
策略 相关 配置 的 这 段 代码 : 


predicateFuncs, err := 
getFitPredicateFunctions(predicateKeys, pluginArgs) 
priorityConfigs, err := 
getPriorityFunctionConfigs(priorityKeys, pluginArgs) 
algo := scheduler.NewGenericScheduler(predicateFuncs, 


priorityConfigs, f.PodLister, r) 
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体 定 义 如 下 : 


type FitPredicate func(pod *api.Pod, existingPods 


[]*api.Pod, node string) (bool, error) 


FitPredicate 是 Pod 调 度 过 程 中 必须 满足 的 规则 ， 只 有 顺利 通过 由 所 
有 FitPredicate 组 成 的 这 道 封锁 线 ， 一 个 Node 才 能 拿 到 主 会 场 的 * 入 场 
券 "， 成 为 一 个 合格 的 “候选 人 ”， 等 待 下 一 步 * 评 审 ”。 目 前 系统 提供 的 
具体 的 FitPredicate 实 现 都 在 predicates.go 里 ， 系 统 默 认 加 载 注册 
FitPredicate 的 地 方 在 defaultPredicates 方 法 里 。 


当 有 一 组 Node 通 过 筛 查 成 为 “候选 人 ”之 后 ， 需 要 有 一 种 办 法 来 选 
择 “ 最 优 ” 的 Node， 这 就 是 接 下 来 我 们 要 介绍 的 priorityConfigs 所 要 做 的 
事情 了 。priorityConfigs 是 一 个 数组 ， 类 型 为 algorithm.PriorityConfig， 
PriorityConfig 包 括 一 个 PriorityFunction 函 数 ， 用 来 计算 并 给 出 一 组 
Node 的 优先 级 ， 下 面 是 相关 代码 : 


type PriorityConfig struct { 
Function PriorityFunction 


Weight int 


type PriorityFunction func(pod *api.Pod, podLister 
PodLister,  minionLister  MinionLister)  (HostPriorityList, 
error) 
type HostPriorityList []HostPriority 
func (h HostPriorityList) Len() int ( 
return len(h) 
} 
func (h HostPriorityList) Less(i, j int) bool { 
if h[i].Score == h[j].Score { 


return h[i].Host < h[j].Host 


return h[i].Score < h[j].Score 


WAR BIS Bide RAK A ERR, MANR FIX Ex 
来 目 genericScheduler 的 计算 候选 节点 优先 级 的 PrioritizeNodes 方 法 ， 你 
束 能 顿悟 了 : 一 个 候选 和 点 的 优先 级 总 分 ent 老师 

(PriorityConfig) 一 起 给 出 的 “加 权 总 分 ”， 评 委 老 师 越 是 德高望重 
(PriorityConfig.Weight 越 大 ) ， 他 的 评分 影响 力 就 越 大 : 


combinedScores := map[string]int{} 
for _, priorityConfig := range priorityConfigs { 
weight := priorityConfig.Weight 
// skip the priority function if the weight is 
specified as 0 


if weight == 0 { 


continue 

} 

priorityFunc := priorityConfig.Function 
prioritizedList, err :- priorityFunc(pod, 


podLister, minionLister) 
if err != nil { 
return algorithm.HostPriorityList{}, err 
} 
for _, hostEntry := range prioritizedList { 
combinedScores[hostEntry.Host] += 


hostEntry.Score * weight 


j 


j 


for host, score :- range combinedScores { 
glog.V(10).Infof("Host %s Score 96d", host, 
score) 
result = append(result, 
algorithm.HostPriority{Host: host, Score: score}) 


j 


return result, nil 


接 下 来 ， 我 们 看 看 系统 初始 化 加 载 的 默认 的 Predicate 与 Priorities 有 
哪些 ， 通 过 追踪 代码 ， 我 们 发 现 默认 加 载 的 代码 位 于 
plugin/pkg/schedulervalgorithmproviderdefaulVydefault.go 的 init 函 数 里 : 


func init() { 


factory.RegisterAlgorithmProvider(factory.DefaultProvider, 
defaultPredicates(), defaultPriorities() ) 

// EqualPriority is a prioritizer function that 
gives an equal weight of one to all minions 

// Register the priority function so that its 

available 

// but do not include it as part of the default 
priorities 

factory.RegisterPriorityFunction("EqualPriority", 


scheduler.EqualPriority, 1) 
} 


跟踪 进去 后 ， 我 们 看 到 系统 默认 加 载 的 predicates 有 如 下 几 种 : 


e PodFitsResources; 
MatchNodeSelector; 


e HostName ° 


而 默认 加 载 的 priorities 则 有 如 下 几 种 : 


e LeastRequestedPriority; 


BalancedResourceAllocation; 


ServiceSpreadingPriority ° 


从 上 述 这 些 信息 来 看 ，Kubernetes 默 认 的 调度 指导 原则 是 尽量 均 
匀 分 布 Node 到 不 同 的 Node 上， 并 且 确 保 各 个 Node 上 的 资源 利用 率 基 本 
你 持 一 人 怪 ， 也 就 是 说 如 果 你 有 100 台 机 絮 ， 则 可 能 每 个 机 器 都 被 调度 
到 ， 而 不 是 只 有 其 中 的 20% 被 调度 到 ， 哪 怕 每 台 机 器 都 只 利用 了 不 到 
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接 下 来 我 们 以 服务 亲 和 人 性 这 个 默认 没有 加 载 的 Predicate 为 例 ， 看 
看 Kubernetes 是 如 何 通过 Policy 文 件 注 册 加 载 它 的 。 下 面 是 我 们 定义 的 
一 个 Policy 文 件 : 


"kind" : "Policy", 
"version" : "vi", 
"predicates" : [ 
{"name" : "RegionZoneAffinity", "argument" 


: ("serviceAffinity" : {"labels" : ["region", "zone"]}}} 


], 
"priorities" : [ 


{"name" : "RackSpread", "weight" : 1, 
"argument" : {"serviceAnti 
Affinity" : {"label" : "rack"}}} 


] 


首先 ， 这 个 文件 被 映射 成 apiPolicy 对 R 
(plugin/pkg/scheduler/api/types.go) 。 下 面 是 其 结构 体 定义 : 


type Policy struct { 
api.TypeMeta ~json:",inline"~ 
// Holds the information to configure the fit 
predicate functions 
Predicates []PredicatePolicy '^json:"predicates"' 
// Holds the information to configure the priority 
functions 


Priorities []PriorityPolicy “json: "priorities" 
我 们 看 到 policy 文 件 中 的 predicates 部 分 被 映射 为 PredicatePolicy 数 


组 : 


type PredicatePolicy struct { 


Name string ~json:"name"~ 


Argument *PredicateArgument ‘json:"argument"’ 


而 PredicateArgument 的 定义 如 下 ， 包 括 服 务 杀 和 性 的 相关 属性 
ServiceAffinity: 


type PredicateArgument struct { 
ServiceAffinity *ServiceAffinity 
“json: "serviceAffinity" 
LabelsPresence *LabelsPresence 


*json:"labelsPresence"- 


j 
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ig 则 2 给 下 gd 的 EQ 数 进行 处 理 
(plugin/pkg/scheduler/factory/plugin.go) 


func RegisterCustomFitPredicate(policy 
schedulerapi.PredicatePolicy) string ( 
var predicateFactory FitPredicateFactory 
var ok bool 
validatePredicateOrDie(policy) 
// generate the predicate function, if a custom 
type is requested 
if policy.Argument !- nil { 
if policy.Argument.ServiceAffinity !- nil { 


predicateFactory - func(args 


PluginFactoryArgs) algorithm.FitPredicate { 
return 
predicates .NewServiceAffinityPredicate( 
args.PodLister, 
args.ServiceLister, 


args.NodeInfo, 


policy.Argument.ServiceAffinity.Labels, 


) 
j 


) else if policy.Argument.LabelsPresence != 
nil { 
predicateFactory - func(args 
PluginFactoryArgs) algorithm.FitPredicate ( 
return 
predicates.NewNodeLabelPredicate( 


args.NodeInfo, 
policy.Argument.LabelsPresence.Labels, 


policy.Argument.LabelsPresence.Presence, 


) 
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predicates.NewServiceAffinityPredicate 方 法 来 创建 一 个 处 理 服 务 亲 和 性 


的 FitPredicate， 随 后 被 加 载 到 全 局 的 predicateFactory 中 生效 。 


最 后 ，genericScheduler. Schedule 方法 才 是 真正 实现 Pod 调 度 的 方 
法 ， 我 们 看 看 这 段 完整 代码 : 


func (g *genericScheduler) Schedule(pod *api.Pod, 
minionLister algorithm.MinionLister) (string, error) { 

minions, err :- minionLister.List() 

if err != nil ( 


return "", err 


} 

if len(minions.Items) == 0 { 
return "", ErrNoNodesAvailable 

} 


filteredNodes, failedPredicateMap, err 
findNodesThatFit(pod, g.pods, g.predicates, minions) 
if err != nil { 


return "", err 


priorityList, err :- PrioritizeNodes(pod, g.pods, 
g.prioritizers, algorithm.FakeMinionLister(filteredNodes)) 
if err != nil { 
return "", err 


} 
if len(priorityList) == 0 { 


return "", &FitError{ 
Pod: pod, 


FailedPredicates: failedPredicateMap, 


return g.selectHost(priorityList) 


这 段 代 码 已 经 简单 得 不 能 再 简单 了 ， 因 为 该 干 的 活 都 已 经 被 
predicates Jj priorities F T! 染 构 之 美 ， 束 在 于 程序 逻辑 分 解 得 恰 到 
好 处 ， 每 个 组 件 各 司 其 职 ， 从 而 化 索 为 和 洽 ， 使 得 主体 流程 清晰 直观 ， 
犹如 行云流水 ， 一 气 呵 成 。 


问 谷 歌 大 神 们 致敬 ! 


6.4.3 ”设计 总 结 


与 之 前 的 Kubernetes API Server 和 Kubernetes Controller Mangager 对 
比 ，Kubernetes Scheduler Server 的 设计 和 代码 显得 更 为 “精妙 ”。 项目 
中 引入 ratelimit 组 件 来 解决 Pod 调 度 的 流 控 问 题 的 做 法 ， 既 大 大 简化 了 
代码 量 ， 又 体现 了 大 神 们 的 气度 。 


Kubernetes Scheduler Server 的 一 个 关键 设计 目标 是 “插件 化 ”， 以 
方便 Cloud Provider 或 者 个 人 用 户 根据 自己 的 需求 进行 定制 ， 本 节 我 们 
绕 其 中 最 为 天 键 的 “fitPredicate 与 PriorityFunction” 对 其 设计 做 一 个 总 
结 。 如 图 6.7 所 示 ， 在 plugin.go 中 采用 了 全 局 变量 的 Map 变 量 记录 了 系 
统 当 前 注册 的 FitPredicate 与 PriorityFunction ， 其 中 fitPredicateMap 和 
priorityFunctionMap 分 别 存放 FitPredicateFactory 与 PriorityConfigFactory 

(包含 了 PriorityFunctionFactory 的 一 个 引用 ) 中 。 可 以 看 出 ， 这 里 的 
设计 采用 了 标准 的 工厂 模式 ，factory.PluginFactoryArgs 这 个 数据 结构 
可 以 认为 是 一 个 上 下 文 环境 变量 ， 它 提供 给 PluginFactory 必 要 的 数据 
访问 接口 ， 比 如 获取 一 个 Node 的 详细 信息 并 获取 一 个 Pod 上 的 所 有 
Service 信息 等 ， 这 些 接 口 可 以 被 某 些 具体 的 FitPredicate 或 
PriorityFunction 使 用 ， 以 实现 特定 的 功能 ， 如 图 6.7 所 示 的 
predicates.PodFitsPods fll priorities.LeastRequestedPriority Wi 77 5] 1E Hj. T 
上 述 接 口 。 
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PI EEE SOU oho DEE Á Create 


; Refer » 


factory.PluginFactoryArgs * 


| A 

| i algorithm.FitPredicate 
v i GetNodeInfo 

; > : \ Realize 


factory.PriorityConfigFactory 


; PodFitsPorts PodFitsHost 
Contains i 
Use , 
个 GetPodServices 
factory.PriorityFunctionFactory algorithm PriorityFunction 


ic reate 
= 


— BalancedResourceA llocation 


[6.7 Kubernetes Scheduler Server 调 上 度 策略 相关 设计 示 
= 


JON 


我 们 注意 到 PluginFactoryArgs 的 接口 都 是 Kubernetes 的 资源 访问 接 
口 ， 那 么 问题 就 来 了 ， 为 何不 直接 用 Kubernetes RestClient API 访 问 
呢 ? 一 个 主要 的 原因 是 如 末 这 样 做 ， 则 增加 了 插件 开发 者 开发 和 调 测 
的 难度 ， 因 为 开发 者 需要 再 去 学 习 和 掌握 RestClient;， 另外 一 个 原因 是 
效率 的 问题 ， 如 有 果 大 家 都 采用 框架 提供 的 “标准 方法 ”查询 资源 ， 那 么 
框架 可 以 实现 很 多 优化 ， 比 较 容 易 缓存 ;最 后 一 个 原因 则 与 之 前 我 们 
分 析 的 “Assumed Pod"” 有 关 ， 即 查询 当前 已 经 调度 过 的 Pod 列 表 是 有 其 
特殊 性 的 ，PluginFactoryArgs HY PodLister 77 7% W æ 5| A T 
ConfigFactoryHJPodLister ° 


algorithmProviderMap 这 个 全 局 变量 则 保存 了 一 组 命名 的 调度 策略 
配置 文件 《AlgorithmProviderConfig) ， 其 实 就 是 一 组 FitPredicate 与 
PriorityFunction 的 集合 ， 其 定义 如 下 : 


type AlgorithmProviderConfig struct { 
FitPredicateKeys util.StringSet 


PriorityFunctionKeys util.StringSet 


它 的 作用 是 预 配 置 和 目 定 义 调度 规则 ^ Kubernetes Scheduler 
Server 默 认 加 载 了 一 个 名 为 “DefaultProvider” 的 调度 策略 配置 ， 通 过 定 
义 和 加 载 不 同 的 调度 规则 配置 文件 ， 我 们 可 以 改变 默认 的 调度 策略 ， 
比如 我 们 可 以 定义 两 组 规则 文件 : 其 中 一 个 命名 
为 “function_test_cfg”， 面 问 功 能 测试 ， 调 度 原则 是 尽量 在 最 少 的 机 器 
上 调度 Pod 以 和 省 资源 ;另外 一 个 则 命名 为 performance_test_cfg”， 面 
回 性 能 测试 ， 调 度 原 则 是 尽 可 能 使 用 更 多 的 机 器 ， 以 测试 系统 性 能 。 


顺便 提 一 下 ， 笔 者 认为 在 Kubernetes Scheduler Server 中 关于 
PredicateArgument/PriorityArgument 的 设计 并 不 好 ， 这 里 没有 将 
Predicate 的 属性 通用 化 ， 比 如 采用 key-value 这 种 模式 ， 因 此 导致 Policy 
文件 格式 与 Predicate/Priority 天 联 之 间 的 强 耦 合 性 ， 增 加 了 代码 理解 的 
困难 性 ， 之 前 分 析 的 Policy 文 件 中 服务 亲 和 人 性 的 Predicate 的 加 载 逻 辑 即 
反映 了 这 个 问题 ， 笔 者 深信 ， 未 来 版 本 中 大 神 们 会 认真 考虑 重 构 问 


题 。 


至 此 ，Master 世 点 上 的 进程 的 源码 都 已 经 分 析 完 毕 ， 我 们 发 现 这 
HERE AT AIS te, JARRE aie ES: Pod 调 度 + 智 能 纠 错 ， 这 也 
征 为 什么 这 些 进 程 所 在 的 和 节点 被 称 为 "Master"”， 因 为 它们 高 高 在 上 ， 
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痒 、 日 理 万 机 ， 计 算 机 的 世界 果然 比 我 们 人 类 的 世界 要 单纯 、 高 效 很 
真心 希望 人 工 智 能 的 发 展 不 会 让 它们 的 世界 也 变 得 扑朔迷离 。 


多 ， 


6.5 “kubeletj 井 程 源 码 分 析 


kubelet 是 运行 在 Minion 节 点 上 的 重要 守护 进程 ， 是 工作 在 一 线 的 
重要 “工人 ”， 它 才 是 负责 “实例 化 > 和 “启动 ”一 个 具体 的 Pod 的 幕后 主 
导 ， 并 且 掌 管 着 本 和 点 上 的 Pod 和 容 属 的 全 生命 周期 过 程 ， 定 时 辣 
Master 汇 报 工作 情况 。 此 外 ，kubeletj 进 程 也 是 一 个 “Server 进 程 ， 它 默 
认 监 听 10250 端 口 ， 接 收 并 执行 远程 (Master) 发 来 的 指令 。 


下 面 我 们 分 别 对 其 启动 过 程 、 关 键 代码 分 析 及 设计 总 结 等 方面 进 
行 深入 分 析 和 讲解 。 


6.5.1 进程 局 动 过 程 


kubelet 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kubelet/kubel 


et.go 


入 口 main () 函数 的 逻辑 如 下 : 


func main() { 
runtime .GOMAXPROCS(runtime.NumCPU( ) ) 
s := app.NewKubeletServer ( ) 
s.AddFlags(pflag.CommandLine) 
util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 
verflag.PrintAndExitIfRequested() 
if err :- s.Run(pflag.CommandLine.Args()); err !- 
nil { 
fmt.Fprintf(os.Stderr, "%v\n", err) 


os.Exit(1) 
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达 99% ， 这 至 少 说 明 一 点 : 谷歌 在 源码 一 致 性 方面 做 得 很 好 ，N 多 人 
写 的 代码 看 起 来 束 好 像 出 目 一 个 人 之 手 。 我 们 先 来 看 看 KubeletServer 
这 个 结构 体 所 包括 的 属性 吧 ， 这 些 属性 可 以 分 为 以 下 几 组 。 


1) 基本 配置 


KubeConfig: kubelet 默 认 配置 文件 路 径 。 

Address ^ Port ^ ReadOnlyPort ^ CadvisorPort ^ HealthzPort ^ 

HealthzBindAddress: 为 kubelet 绑 定 监 听 的 地 址 ， 包 括 上 自身 Server 

的 地 址 ，Cadvisor 绑 定 的 地 址 ， 以 及 目 号 健康 检查 服务 的 绑 定 地 

址 等 。 

RootDirectory ^ CertDirectory : kubelet 默认 的 工作 目录 
(/var/lib/kubelet) ， 用 于 存放 配置 及 VM 卷 等 数据 ，CertDirectory 

用 于 存放 证 书目 录 。 


2) 管理 Pod 和 容器 相关 的 参数 


PodInfraContainerImage: Pod 的 infra 容 妖 的 镜像 名 称 ， 合 歌 被 屏 菩 

的 时 候 可 以 换 成 自己 的 私有 仓库 的 镜像 名 。 

CgroupRoot: 可 选项 ， 创 建 Pod 的 时 候 所 使 用 的 顶层 的 cgroop 名 字 
(Root Cgroup) 

ContainerRuntime ^ DockerDaemonContainer ^ SystemContainer : 

这 三 个 参数 分 别 表示 选择 什么 容器 技术 (Docker 2% # RKT) 

Docker Daemon 容 絮 的 名 字 及 可 选 的 系统 资源 容器 名 称 ， 用 来 将 

所 有 非 kernel 的 、 不 在 容器 中 的 进程 放 入 此 容器 中 。 


3) 同步 和 目 动 运 维 相关 的 参数 


SyncFrequency ^ FileCheckFrequency ~ HTTPCheckFrequency: Pod 
容 絮 同步 周期 、 当 前 运行 的 容 絮 实例 分 别 与 Kubernetes 注 册 表 中 
的 信息 、 本 地 的 Pod 定 义 文件 及 以 HTTP 方 式 提供 信息 的 数据 源 进 
行 对 比 同步 。 

RegistryPullQPS ` RegistryBurst: 从 注册 表 拉 取 待 创建 的 Pod 列 表 
时 的 流 探 参 数 。 

NodeStatusUpdateFrequency: kubelet 多 入 汇报 一 次 当前 Node 的 状 
A o 


ImageGCHighThresholdPercent ` ImageGCLowThresholdPercent ` 

LowDiskSpaceThresholdMB: 分 别 是 Image 镜 像 占 用 磁盘 空间 的 高 
低 水 位 国 值 及 本 机 磁 僵 最 小 空 朵 容量 ， 当 可 用 容量 低 于 这 个 容量 
时 ， 所 有 新 Pod 的 创建 请 求 会 被 拒绝 。 


MaxContainerCount ^ MaxPerPodContainerCount : 分 别 是 
maximum-dead-containers 5 maximum-dead-containers-per- 


container, NRA SETLIST EE, AAS 
X ARSAM ERKA, P A S fug. Rize 
MaxContainerCount7j 100, MaxPerPodContainerCount7j2, BEA 
容 絮 你 留 最 多 两 个 死亡 实例 ， 每 个 Node 保 留 最 多 100 个 死亡 实 
例 。 


只 要 分 析 一 下 上 述 KubeletServer 结 构 体 的 关键 属性 ， 我 们 就 可 以 


得 到 这 样 一 个 推论 : kubelet 进 程 的 “工作 量 ” 还 是 很 饱满 的 ， 一 点 都 不 


比 Master 上 的 API Server ` Controll Manager、Scheduer 做 得 少 。 


在 继续 下 面 的 代码 分 析 之 前 ， 我 们 先 要 理解 这 里 的 一 个 重要 概 


“Pod Source”， 它 是 kubelet 用 于 获取 Pod 定 义 和 摘 述 信 息 的 一 个 “数据 


源 ”，kubelet 进 程 查 询 并 监听 Pod Source 来 获取 属于 自己 所 在 节点 的 Pod 
列表 ， 当 前 支持 三 种 Pod Source 类 型 。 


e Config File: 本 地 配置 文件 作为 Pod 数 据 源 。 
e Http URL: Pod 数 据 源 的 内 容 通 过 一 个 HTTP URL 方 式 获取 。 
e Kubernetes API Server: 默认 方式 ， 从 API Server 获 取 Pod 数 据 源 。 


进程 根据 启动 参数 创建 了 KubeletServer 以 后 ， 调 用 KubeletServer 
的 run 方 法 ， 进 入 启动 流程 ， 人 H gus 
oom adj Z& (默认 为 -900) ， 这 是 利用 了 Linux 的 OOM 机 制 ， 当 系统 
发 生 OOM 时 ，oom_adj 的 值 越 小 ， 越 不 容易 被 系统 Kill 掉 o 


if err := util.ApplyOomScoreAdj(0, s.OOMScoreAdj); err 
I= nil { 


glog.Warning(err) 


HITA FEZ BAY Master T AA ERE E SPI ss) y. mE 
kubelet 进 程 上 却 看 到 这 段 逻 辑 ? ASS, KAA Master T 点 不 运行 
Pod 和 容 右 ， 主 机 资源 通常 是 稳定 和 宽裕 的 ， 而 Minion 世 点 由 于 需要 运 
行 大 量 的 Pod 和 容器 ， 因 此 容易 产生 OOM 问 题 ， 所 以 这 里 要 确保 “守护 
者 ”不 会 因此 而 被 系统 Kil 掉 。 


由 于 kubelet 会 跟 API Server 打 交道 ， 所 以 接 下 来 创建 了 一 个 Rest 
Client 对 象 来 访问 API Server ° 随后， 局 动 进 程 构造 了 cAdvisor 来 监控 
本 地 的 Docker 容器 , cAdvisor 具体 的 创建 代码 则 位 于 
pkg/kubelet/cadvisor/cadvisor_linux.go Ed 5| 用 了 
github.com/google/cadvisor 这 个 同样 属于 谷歌 开源 的 项 目 。 


接着 ， 初 始 化 CloudProvider， 这 是 因为 如 果 Kubernetes 运 行 在 某 个 
运 萌 商 的 Cloud 环 境 中 ， 则 很 多 环境 和 资源 都 需要 从 CloudProvider 中 获 
取 ， 比 如 在 创建 Pod 的 过 程 中 可 能 需要 知道 某 个 Node 的 真实 主机 名。 


虽然 容 需 可 以 绑 定 牡 主 机 的 网 络 空间 ， 但 大 不 当 使 用 会 导致 系统 
安全 漏洞 ， 所 以 KubeletServer 中 的 HostNetworkSources 的 属性 用 来 控制 
哪些 Pod 人 允许 绑 定 笨 主机 的 网 络 空间 ， 默 认 是 都 蔡 止 绑 定 。 举 例 说 
明 ， 比 如 设置 HostNetworkSources=api，http ， 则 表明 当 一 个 Pod 的 定义 
源 来 自 Kubernetes API Server 或 者 某 个 HTTP URL 时 ， 则 允许 此 Pod 绑 
定 到 答 主 机 的 网 络 空间 。 下 面 这 行 代码 即 上 述 处 理 逻 辑 中 的 一 小 部 


分 : 


hostNetworkSources, err = 
kubelet.GetValidatedSources(strings.Split(s.HostNetworkSour 


ces, UI) 


接 下 来 加 载 数 字 证 书 ， 如 果 没 有 提供 证 书 和 私 铀 ， 则 默认 创建 一 
个 目 签 名 的 X509 证 书 并 保存 到 本 地 。 下 一 步 ， 创 建 一 个 Mounter 对 
象 ， 用 来 实现 容 右 的 文件 系统 挂 载 功能 。 


接 下 来 的 这 上 段 代 码 根 据 指定 了 DockerExecHandlerName 参 数 的 
值 ， 确 定 dockerExecHandler 是 采用 Docker 的 exec 命 令 还 是 nsenter 来 实 
现 ， 默 认 采 用 了 Docker 的 exec 这 种 本 地 方式 ，Docker 从 1.3 版 本 开始 提 
供 了 exec 指 令 ， 为 进入 容器 内 部 提供 了 更 好 的 手段 。 


var dockerExecHandler dockertools.ExecHandler 
switch s.DockerExecHandlerName { 


case "native": 


dockerExecHandler = 
&dockertools.NativeExecHandler {} 
case "nsenter": 
dockerExecHandler = 
&dockertools.NsenterExecHandler {} 
default: 
log.Warningf ("Unknown Docker exec handler 
%q; defaulting to native", s.DockerExecHandlerName) 
dockerExecHandler = 


&dockertools.NativeExecHandler {} 


j 


运行 至 此 ， 程 序 构造 了 一 个 KubeletConfig 结 构 体 ，90% 的 变量 与 
之 前 的 KubeletServer 一 样 ， 这 让 代码 长 度 增加 了 20 多 行 ! 定 睛 一 看 ， 
源码 上 有 TODO 注 释 :“ 它 应 该 可 能 被 合并 到 KubeletServer 里 ..…..….…. ” H 
测 注 释 是 另外 一 个 大 神 添加 的 ， 这 让 笔者 陷入 了 深 深 的 思考 : 难道 合 
歌 的 绩效 考评 系统 中 也 有 恶俗 的 代码 行 数 考核 指标 ? 


KubeletConfig 创 建 好 以 后 作为 参数 调用 RunKubelet (&kcfg, nil) 
方法 ， 程 序 运 行 到 这 里 ， 才 真正 进入 流程 的 核心 步 又。 下 面 这 段 代 码 
表明 kubelet 会 把 自己 的 事件 通知 API Server: 


eventBroadcaster := record.NewBroadcaster() 
kcfg.Recorder - 
eventBroadcaster.NewRecorder(api.EventSource(Component : 
"kubelet", Host: kcfg.NodeName} ) 


eventBroadcaster.StartLogging(glog.V(3).Infof) 


if kcfg.KubeClient != nil { 
glog.V(4).Infof("Sending events to api 


server.") 


eventBroadcaster.StartRecordingToSink(kcfg.KubeClient.Event 
s("")) 
) else ( 
glog.Warning("No api server defined - no 


events will be sent to API server.") 


j 


接 下 来 ， 启 动 进 程 进入 关键 函数 createAndInitKubelet 中 ， 这 里 首 
先 创建 一 个 PodConfig 对 象 ， 并 根据 启动 参数 中 Pod Source 参 数 是 否 提 
供 ， 来 创建 相应 类 型 的 Pod Source 对 象 ， 这 些 PodSource 在 UE 
运行 ， 拉 取 Pod 信 息 并 汇总 输出 到 同一 个 Pod Channel "P? $$ fr kubelet 4h 
理 。 创 建 PodConfig 的 具体 代码 如 下 : 


func  makePodSourceConfig(kc *KubeletConfig) 
*config.PodConfig { 
// source of all configuration 
cfg := 
config .NewPodConfig(config.PodConfigNotificationSnapshotAnd 


Updates, kc.Recorder) 


// define file config source 
if kc.ConfigFile !- "" { 


glog.Infof("Adding manifest file: %v", 


kc .ConfigFile) 
config.NewSourceFile(kc.ConfigFile, 
kc .NodeName, kc.FileCheckFrequency, 


cfg.Channel(kubelet.FileSource)) 
} 


// define url config source 
if kc.ManifestURL !- "" { 
glog.Infof("Adding manifest url: %v", 
kc.ManifestURL) 
config.NewSourceURL(kc.ManifestURL, 
kc .NodeName, kc. HTTPCheckFrequency, 
cfg.Channel(kubelet.HTTPSource)) 
} 
if kc.KubeClient != nil { 
glog.Infof("Watching apiserver") 
config.NewSourceApiserver(kc.KubeClient, 
kc.NodeName, cfg.Channel(kubelet.ApiserverSource)) 


j 


return cfg 


然后 ， 创 建 一 个 kubelet 并 宣告 它 的 诞生 : 


k, err = kubelet.NewMainKubelet(...) 


k.BirthCry() 


BUE, fit AkubeletH Jci Sz 3 AIC tap EAS BC FB ETE ie 0 a RR 
FRATE, BT ee CSB: 


// Starts garbage collection threads. 
func (kl *Kubelet) StartGarbageCollection() { 
go util.Forever(func() (1 
if err :- kl.containerGC.GarbageCollect(); err 
I= nil { 
glog.Errorf("Container garbage collection 
failed: %v", err) 


j 


), time.Minute) 


go util.Forever(func() (1 
if err :- kl.imageManager.GarbageCollect(); 
err !- nil { 
glog.Errorf("Image garbage collection 
failed: %v", err) 


j 


), 5*time.Minute) 


createAndInitKubelet 方 法 创建 kubelet 实 例 以 后 ， 返 回 到 RunKubelet 
方法 里 ， 接 下 来 调用 startKubelet 方 法 ， 此 方法 首 移 局 动 一 个 协 程 ， 让 
kubelet 处 38 2€ E] PodSource 的 Pod Update 7B A, % Ja JA 3) Kubelet 
Server, PIERII: 


func startKubelet(k  KubeletBootstrap,  podCfg 
*config.PodConfig, kc *KubeletConfig) { 
// start the kubelet 
go util.Forever(func() { k.Run(podCfg.Updates()) 
j, 9) 


// start the kubelet server 
if kc.EnableServer ( 
go util.Forever(func() { 
k.ListenAndServe(net.IP(kc.Address), 
kc.Port, kc.TLSOptions, kc.EnableDebuggingHandlers) 
j, 9) 
} 
if kc.ReadOnlyPort > 0 { 


go util.Forever(func() { 


k.ListenAndServeReadOnly(net.IP(kc.Address), 


kc.ReadOnlyPort) 
j, 0) 


至 此 ，kubeletj 井 程 局 动 完毕 。 


6.5.2 ”关键 代码 分 析 


6.5.1 世 里， 我 们 分 析 了 kubelet 进 程 的 启动 流程 ， 大 致 明白 了 
kubelet 的 核心 工作 流程 束 是 不 断 从 PodSource 中 获取 与 本 和 点 相关 的 
Pod， 然 后 开始 “加 工 处 理 *?"， 所 以 ， 我 们 先 来 分 析 Pod Source 部 分 的 代 
码 。 前 面 我 们 提 人 到，kubelet 可 以 同时 支持 三 类 Pod Source， 为 了 能 够 将 
不 同 的 Pod Source“ 汇 聚 ?到 一 起 统一 处 理 ， 谷 歌 特地 设计 了 PodConfig 
这 个 对 象 ， 其 代码 如 下 : 


type PodConfig struct { 
pods *podStorage 


mux *config.Mux 


// the channel of denormalized changes passed to 


listeners 


updates chan kubelet.PodUpdate 


// contains the list of all configured sources 
sourcesLock sync.Mutex 


sources util.StringSet 


其 中 ，sources 属 性 包括 了 当前 加 载 的 所 有 Pod Source X 7! , 
sourcesLock 是 source 的 排他 锁 ， 在 新 增 Pod Source 的 方法 里 使 用 它 来 避 


免 共 享 冲 突 。 


当 Pod 发 生变 动 时 ， 例 如 Pod 创 建 、 删 除 或 者 更 新 ， 相 天 的 Pod 
Source 束 会 产生 对 应 的 PodUpdate 事 件 并 推送 到 Channel E ° A T RE 
统一 处 理 来 目 多 个 Source 的 Channel， 人 谷歌 设计 了 config.Mux 这 个 “聚合 
絮 ”， 它 负责 监听 多 路 Channel， 当 接收 到 Channel 发 来 的 事件 以 后 ， 交 
给 Merger 对 象 进行 统一 处 理 ，Merger 对 象 最 终 把 多 路 Channel 发 来 的 事 
件 合并 写 入 updates 这 个 汇聚 Channel 里 等 待 处 理 。 


下 面 是 config.Mux 的 结构 体 定 义 ， 其 属性 sources 为 一 个 Channel 
Map，key 是 对 应 的 Pod Source 的 类 型 : 


type Mux struct { 
// Invoked when an update is sent to a source. 
merger Merger 
// Sources and their lock. 
sourceLock sync.RWMutex 
// Maps source names to channels 


sources map[string]chan interface{} 


我 们 继续 深入 分 析 config.Mux 的 工作 过 程 ， 前 面 提 到 ，kubelet 在 
局 动 过 程 中 在 makePodSourceConfig 方 法 里 创建 了 一 个 PodConfig 对 
象 ， 并 且 根 据 司 动 参数 来 决定 要 加 载 哪 些 类 型 的 Pod Source， 在 这 个 
过 程 中 调用 了 下 述 方 法 来 创建 一 个 对 应 的 Channel: 


func (c *PodConfig) Channel(source string) chan<- 


interface{} { 


c.sourcesLock.Lock() 
defer c.sourcesLock.Unlock() 
c.sources.Insert(source) 


return c.mux.Channel(source) 


而 Channel 有 具体 的 创建 过 程 则 在 config.Mux 里 ，Channel 创 建 完 成 后 
被 加 入 config.Mux 的 sources 里 并 且 启 动 一 个 协 程 开 始 监听 背 息 ， 代 码 
如 下 : 


func (m *Mux) Channel(source string) chan interface{} 


if len(source) == 0 { 

panic("Channel given an empty name") 
} 
m.sourceLock.Lock( ) 
defer m.sourceLock.Unlock() 
channel, exists :- m.sources[source] 
if exists ( 

return channel 
} 
newChannel := make(chan interface{}) 
m.sources[source] = newChannel 

go util.Forever(func() { m.listen(source, 
newChannel) }, 0) 


return newChannel 


config.MuxH -Xiilisten7 £148 fal, Wire ux UT sr GI EH Channel, 
一 旦 发 现 Channel 上 有 数据 束 灾 给 Merger 进 行 处 理 : 


func (m *Mux) listen(source string, 


listenChannel <- 
chan interface{}) { 


for update := range listenChannel { 


m.merger.Merge(source, update) 


我 们 先 来 看 看 Pod Source 是 如 何 发 送 PodUpdate 事 件 到 自己 所 在 的 


Channel 上 的 ， 在 6.5.1 节 中 我 们 所 见 到 的 下 面 这 段 代码 创建 了 一 个 
Config File 类 型 的 Pod Source: 


// define file config source 


if kc.ConfigFile !- "" { 


glog.Infof("Adding manifest file: %v", 
kc.ConfigFile) 


config.NewSourceFile(kc.ConfigFile, 
kc.NodeName, kc.FileCheckFrequency, 
cfg.Channel(kubelet.FileSource)) 


j 


f£ NewSourceFile 7; 7 Hi A Ej f — ^ B, 隔 指 定 的 时 间 


(kc.FileCheckFrequency) 就 执行 一 次 SourceFile 的 run 方 法 ， 在 run 方 法 
里 所 调用 的 主体 逻辑 是 下 面 的 函数 : 


func (s *sourceFile) extractFromPath() error { 
path := s.path 
statInfo, err := os.Stat(path) 
if err != nil { 
if !os.IsNotExist(err) { 
return err 
} 
// Emit an update with an empty PodList to 
allow FileSource to be marked as seen 
s.updates <- 
kubelet .PodUpdate{[]*api.Pod{}, kubelet.SET, 
kubelet.FileSource? 
return fmt.Errorf("path does not exist, 
ignoring") 


j 


switch ( 

case statInfo.Mode().IsDir(): 
pods, err :- s.extractFromDir(path) 
if err != nil { 


return err 


s.updates <- kubelet.PodUpdate{pods, 
kubelet.SET, kubelet.FileSource} 


case statInfo.Mode().IsRegular(): 


pod, err := s.extractFromFile(path) 
if err != nil { 


return err 


s.updates <- 
kubelet .PodUpdate{[ ]*api.Pod{pod}, kubelet.SET, 


kubelet .FileSource} 


default: 
return fmt.Errorf("path is not a directory 
or file") 


j 


return nil 


* —HR Emi Bf RE, Fe] et BHA A T Config File 4! HJ Pod 
Source 是 如 何 工 作 的 : 它 从 指定 的 目 孙 中 加 载 多 个 Pod 定 义 文件 并 转换 
为 Pod 列 表 或 者 加 载 单 个 Pod 定 义 文 件 并 转换 为 单个 pod， 然 后 生成 对 
应 的 全 量 类 型 的 PodUpdate 事 件 并 写 入 Channel 中 去 。 这 里 笔者 也 发 现 
了 代码 命名 的 一 个 疏漏 之 处 ，SourceFile 的 updates 必 性 其 实 应 该 被 命名 
为 update。 其 他 两 种 Pod Source 类 型 的 代码 解析 束 不 在 这 里 提 及 了 。 


接 下 来 我 们 分 析 Merger 对 象 ，PodConfig 里 的 Merger 对 象 其 实 是 一 
个 config.podStorage 实 例 ， 它 同时 是 PodConfig 的 pods 属 性 的 一 个 引 
用 。podStorage 的 源码 位 于 pkg/kubelet/config/config.go 里 ， 其 定义 如 
下 : 


type podStorage struct { 
podLock sync.RWMutex 
// map of source name to pod name to pod reference 
pods map[string]map[string]*api.Pod 
mode PodConfigNotificationMode 
// ensures that updates are delivered in strict 
order 
// on the updates channel 
updateLock sync.Mutex 
updates chan«- kubelet.PodUpdate 
// contains the set of all sources that have sent 
at least one SET 
sourcesSeenLock sync.Mutex 
sourcesSeen util.StringSet 
// the EventRecorder to use 


recorder record.EventRecorder 


我 们 看 到 podStorage 的 关键 属性 解释 如 下 。 


(1) pods: 类 型 是 Map， 存 放 每 个 Pod Source 上 拉 过 来 的 Pod 数 
据 ， 是 podStorage 当 前 保存 “全 量 Pod” 的 地 方 。 


(2) updates: 它 就 是 PodConfig 里 的 updates 属 性 的 一 个 引用 。 
(3) mode: 表明 podSstorage 的 Pod 事 件 通知 模式 ， 有 以 下 几 种 。 


。 PodConfigNotificationSnapshot: 全 量 快照 通知 模式 。 


e PodConfigNotificationSnapshotAndUpdates: 全 量 快照 + 更 新 Pod 通 
知 模式 (代码 中 创建 podStorage 实 例 时 采用 的 模式 ) 。 
。 PodConfigNotificationIncremental: 增 量 通知 模式 。 


podStorage 实 现 的 Merge 接 口 的 源码 如 下 : 


func (s *podStorage) Merge(source string, change 
interface{}) error { 
s.updateLock.Lock() 
defer s.updateLock.Unlock( ) 
adds, updates, deletes := s.merge(source, change) 
// deliver update notifications 
switch s.mode { 
case PodConfigNotificationSnapshotAndUpdates: 
if len(updates.Pods) > © { 
s.updates «- *updates 
} 
if len(deletes.Pods) > 0 || len(adds.Pods) 
> 0 { 
s.updates<- 
kubelet.PodUpdate(s.MergedState().([]*api.Pod), 
kubelet.SET, source} 
} 
// 省 略 无 天 的 Case 逻 辑 
} 


return nil 


在 上 述 Merge 过 程 中 ， 移 调用 内 部 函数 merge， 将 Pod Soucre #3 
Channel 上 发 来 的 PodUpdate 事 件 分 解 为 对 应 的 新 增 、 更 新 及 删除 等 三 
类 PodUpdate 事 件 ， 然 后 判断 是 否 有 更 新 事件 ， 如 果 有 ， 则 和 直接 写 入 汇 
总 的 Channel 中 (podStorage.updates) ， 然 后 调用 MergedState 函 数 复制 
一 份 podStorage 的 当前 全 量 Pod 列 表 ， 以 此 产生 一 个 全 量 的 PodUpdate 
事件 并 写 入 汇总 的 Channel 中 ， 从 而 实现 了 多 Pod Source Channel 的 “ 汇 
Bis BB o 


分 析 完 Merger 过 程 以 后 ， 我 们 接 下 来 看 看 是 什么 对 象 ， 以 及 如 何 
消费 这 个 汇总 的 Channel。 在 上 一 市 提 人 到， 在 kubelet 进 程 启动 的 过 程 中 
调用 了 startKubelet 方 法 ， 此 方法 下 和 完 局 动 一 个 协 程 ， 让 kubelet 处 理 来 
和 目 PodSource 的 Pod Update 消 息 ， 即 下 面 这 行 代码 : 


go util.Forever(func() { k.Run(podCfg.Updates()) }, 0) 


其 中 ，PodConfig 的 Updates () 方法 返回 了 前 面 我 们 所 说 的 汇总 
Channel 变 量 的 一 个 引用 ， 下 面 是 kubelet 的 Run ( updates € -chan 
PodUpdate) 方法 的 代码 : 


func (kl *Kubelet) Run(updates «-chan PodUpdate) { 
if kl.logServer -- nil ( 
kl.logServer = http.StripPrefix("/logs/", 
http.FileServer(http.Dir("/var/log/"))) 
} 
if kl.kubeClient == nil { 
glog.Warning("No api server defined - no 


node status update will be sent. ") 


j 


// Move Kubelet to a container. 
if kl.resourceContainer !- "" { 
err = 
util.RunInResourceContainer(kl.resourceContainer) 
if err != nil ( 
glog.Warningf("Failed to move 
Kubelet to container %q: 96v", kl.resourceContainer, err) 
} 
glog.Infof("Running in container %q", 
kl.resourceContainer) 
} 
if err := kl.imageManager.Start(); err != nil { 
kl.recorder.Eventf(kl.nodeRef, "kubeletSetupFailed", 
"Failed to start ImageManager %v", err) 
glog.Errorf("Failed to start ImageManager, 
images may not be garbage collected: %v", err) 
} 
if err := kl.cadvisor.Start(); err != nil { 
kl.recorder.Eventf(kl.nodeRef, 
"kubeletSetupFailed", "Failed to start CAdvisor %v", err) 
glog.Errorf("Failed to start CAdvisor, 
system may not be properly monitored: %v", err) 
} 
if err := kl.containerManager.Start(); err != nil { 
kl.recorder.Eventf(kl.nodeRef, 


"kubeletSetupFailed", "Failed to start  ContainerManager 


9v", err) 
glog.Errorf("Failed to start 
ContainerManager, system may not be properly isolated: %v", 


err) 


if err :- kl.oomwatcher.Start(kl.nodeRef); err !- 
nil { 
kl.recorder.Eventf(kl.nodeRef, 
"kubeletSetupFailed", "Failed to start OOM watcher %v", 
err) 
glog.Errorf("Failed to start OOM watching: 
%v", err) 
} 
go util.Until(kl.updateRuntimeUp, 5*time.Second, 
util.NeverStop) 
// Run the system oom watcher forever. 
kl.statusManager.Start() 


kl.syncLoop(updates, kl) 


上 述 代 码 首 先 局 动 了 一 个 HTTP File Server? ut RPA TAN A 
统 日 志 ， 接 下 来 根据 局 动 参数 的 设置 来 决定 是 否 在 指定 的 Docker 容 器 
中 启动 kubelet 进 程 (如 果 成 功 ， 则 将 本 进程 转移 到 指定 的 容器 中 ) ， 
然后 分 别 启动 Image Manager (f Image GC) 、cAdvisor (Docker 性 
能 监控 ) ^ Container Manager (Container GC) ^ OOM Watcher 

(OOM 监 测 ) ` Status Manager (f St lal ze AN TT A EPodB TAZ ZI) API 


Server E) 等 组 件 ， 最 后 进入 syncLoop 方 法 中 ， 无 限 循环 调用 下 面 的 
syncLooplteration 方 法 : 


func (kl *Kubelet) syncLoopIteration(updates <-chan 
PodUpdate, handler SyncHandler) { 
kl.syncLoopMonitor.Store(time.Now()) 
if !kl.containerRuntimeUp() { 
time.Sleep(5 * time.Second) 
glog.Infof("Skipping pod synchronization, 
container runtime is not up. ") 
return 
} 
if !kl.doneNetworkConfigure() { 
time.Sleep(5 * time.Second) 
glog.Infof("Skipping pod synchronization, 
network is not configured") 
return 
} 
unsyncedPod := false 


podSyncTypes := make(map[types.UID]SyncPodType) 


select { 
case u, Ok := <-updates: 
if !ok { 


glog.Errorf("Update channel is closed. 
Exiting the sync loop.") 


return 


kl.podManager.UpdatePods(u, podSyncTypes) 
unsyncedPod - true 
kl.syncLoopMonitor.Store(time.Now()) 
case «-time.After(kl.resyncInterval): 
glog.V(4).Infof("Periodic sync") 
} 
start := time.Now() 
// If we already caught some update, try to wait 
for some short time 
// to possibly batch it with other incoming 
updates. 
for unsyncedPod { 
select ( 
case u :- «-updates: 
kl.podManager.UpdatePods(u, podSyncTypes) 
kl.syncLoopMonitor.Store(time.Now()) 
case «-time.After(5 * time.Millisecond): 
// Break the for loop. 


unsyncedPod - false 


pods, mirrorPods = 
k1.podManager .GetPodsAndMirrorMap( ) 
kl.syncLoopMonitor.Store(time.Now()) 
if err :- handler.SyncPods(pods, podSyncTypes, 
mirrorPods, start); err != nil { 


glog.Errorf("Couldn't sync containers: %v", 


err) 
} 
kl.syncLoopMonitor.Store(time.Now()) 


j 


在 上 述 代 码 中 ， 如 果 从 Channel 中 拉 取 到 了 PodUpdate 事 件 ， 则 先 
调用 podManager 的 UpdatePods 方 法 来 确定 此 PodUpdate 的 同步 类 型 ， 并 
将 结果 放 入 podSyncTypes 这 个 Map 中 ， 同 时 为 了 提升 处 理 效率 ， 在 代 
码 中 增加 了 持续 循环 拉 取 PodUpdate 数 据 直到 Channel 为 空 为止 (超时 
判断 ) 的 一 段 逻 辑 。 在 方法 的 最 后 ， 调 用 SyncHandler 接 口 来 完成 Pod 
同步 的 具体 逻辑 ， 从 而 实现 了 PodUpdate 事 件 的 高 效 批 处 理 模式 。 


SyncHandler 在 这 里 葡 是 kubelet 实 例 本 喘 ， 它 的 SyncPods 方 法 比较 
长 ， 其 主要 逻辑 如 下 。 


将 传 入 的 全 量 Pod， 与 statusManager 中 当前 保存 的 Pod 集 合 进行 对 
比 ， 删 除 statusManager 中 当前 已 经 不 存在 的 Pod 〈 孤 儿 Pod) 
调用 kubelet 的 admitPods 方 法 以 过 滤 掉 不 适合 本 市 点 创建 的 Pod。 
此 方法 首先 过 滤 挥 状态 为 Failed 或 者 Succeeded 的 Pod; 接着 过 滤 挥 
不 适合 本 和 点 的 Pod， 比 如 Host Port 冲 突 、Node Label 的 约束 不 匹 
配 及 Node 的 可 用 资源 不 足 等 情况 ， 最 后 检查 人 磁盘 的 使 用 情况 ， 如 
果 磁 副 的 可 用 空间 不 足 ， 则 过 滤 掉 所 有 Pod 。 
对 上 述 过 小 后 的 Pod 集 合 中 的 每 一 个 Pod 调 用 podWorkers 的 
UpdatePod 方 法 ， 而 此 方法 内 部 创建 了 一 个 Pod 的 workUpdate 事 件 
并 发 布 到 该 Pod 对 应 的 一 个 WorkChannel 上 
(podWorkers.podWorkers) 


。 对 于 已 经 删除 或 不 存在 的 Pod， 通 知 podWorkers 删 除 相 关联 的 
WorkChannel (workUpdate) 。 

e 对 比 Node 当 前 运行 中 的 Pod 及 目标 Pod 列 表 , “ATH” ERAP, 
并 且 调 用 DockerRuntime (Docker Deamon 进 程 ) API， 重 新 获取 
当前 运行 中 的 Pod 列 表 信 息 。 
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要 真正 理解 Pod 是 怎么 在 Node 上 “落地 ”的 ， 还 要 继续 深入 分 析 上 
述 第 3 步 的 代码 。 首 先 我 们 看 看 对 workUpdate 这 个 结构 体 的 定义 : 


type workUpdate struct { 
pod *api.Pod 
// The mirror pod of pod; nil if it does not exist. 
mirrorPod *api.Pod 
// Function to call when the update is complete. 
updateCompleteFn func() 


updateType SyncPodType 


其 中 的 属性 pod 是 当前 要 操作 的 Pod 对 象 ，mirrorPod 则 是 对 应 的 镜 
像 Pod， 下 面 是 对 它 的 解释 : 


“对 于 每 个 来 目 非 API Server Pod Source 上 的 Pod，kubelet 都 在 API 
Server 上 注册 一 个 几乎 "一模一样 > 的 Pod， 这 个 Pod 被 称 为 mirrorPod , 
IER, KEAN TA Pod Source 上 的 Pod 都 “统一 ”到 了 kubelet 的 注册 
表 上 ， 从 而 统一 了 Pod 生 命 周 期 的 管理 流程 。” 


workUpdate 的 updateCompleteFn 属 性 是 一 个 回调 函数 ，work 完 成 
后 会 执行 此 回调 函数 ， 在 上 述 第 3 步 中 ， 此 函数 用 来 计算 该 work 的 调 
度 时 延 指 标 。 


对 于 每 个 要 同步 的 Pod，podWorkers 会 用 一 个 长 度 为 1 的 Channel 来 
存放 其 对 应 的 workUpdate， 而 属性 lastUndeliveredWorkUpdate 则 存放 最 
近 一 个 待 安排 执行 的 workUpdate ， 这 是 因为 一 个 Pod 的 前 一 个 
workUpdate 正 在 执行 的 时 候 ， 可 能 会 有 一 个 新 的 PodUpdate 事 件 需 要 处 
理 。 理 解 了 这 个 过 程 后 ， 再 来 看 podWorkers 的 定义 ， 束 不 难 了 : 


type podWorkers struct { 
// Protects all per worker fields. 
podLock sync.Mutex 
podUpdates map[types.UID]chan workUpdate 
isWorking map[types.UID]bool 
lastUndeliveredWorkUpdate map[types.UID]workUpdate 
runtimeCache kubecontainer.RuntimeCache 
syncPodFn syncPodFnType 


recorder record.EventRecorder 


T ax +S ER TALL Ze 58 329. E 77 4 workUpdate 3& fF JF a A 81] 
podWorkersR X] NChannell] 7; TX HJ 1E £4: 


func (p *podWorkers) UpdatePod(pod *api.Pod, mirrorPod 
*api.Pod, updateComplete func()) { 
uid :- pod.UID 


var podUpdates chan workUpdate 
var exists bool 

updateType := SyncPodUpdate 
p.podLock.Lock( ) 

defer p.podLock.Unlock() 


if podUpdates, exists - p.podUpdates[uid]; !exists 


{ 
podUpdates = make(chan workUpdate, 1) 
p.podUpdates[uid] = podUpdates 
updateType = SyncPodCreate 
go func() ( 
defer util.HandleCrash() 
p.managePodLoop(podUpdates) 
}() 
} 
if !p.isWorking[pod.UID] { 
p.isWorking[pod.UID] = true 
podUpdates <- workUpdate{ 
pod: pod, 
mirrorPod: mirrorPod, 
updateCompleteFn: updateComplete, 
updateType: updateType, 
2 
} else { 
p.lastUndeliveredWorkUpdate[pod.UID] = 
workUpdate{ 


pod: pod, 


mirrorPod: mirrorPod, 
updateCompleteFn: updateComplete, 


updateType: updateType, 


上 面 的 代码 会 调用 podWorkers 的 managePodLoop 方 法 来 处 理 
podUpdates 队 列 ， 这 里 主要 是 获取 必要 的 参数 ， 最 终 处 理 又 转手 交 给 
syncPodFn 方 法 去 处 理 。 下 面 是 managePodLoop 的 源码 : 


func (p *podworkers) managePodLoop(podUpdates <-chan 
workUpdate) ( 
var minRuntimeCacheTime time.Time 
for newwork :- range podUpdates ( 
func() ( 
defer p.checkForUpdates(newWork.pod.UID, 
newWork.updateCompleteFn) 
if err : = 
p.runtimeCache.ForceUpdateIfOlder(minRuntimeCacheTime); err 
I- nil { 
glog.Errorf("Error updating the container runtime 
cache: %v", err) 
return 
} 
pods, err := p.runtimeCache.GetPods() 


if err != nil { 


glog.Errorf("Error getting pods while 
syncing pod: %v", err) 


return 


err = p.syncPodFn(newWork.pod, 


newwork.mirrorPod, 


kubecontainer.Pods(pods).FindPodByID(newWork.pod.UID), 
newWork.updateType) 
if err != nil ( 
glog.Errorf("Error syncing pod %s, skipping: %v", 
newWork.pod.UID, err) 
p.recorder.Eventf(newWork.pod, "failedSync", "Error 
syncing pod, skipping: %v", err) 
return 
} 
minRuntimeCacheTime = time.Now() 
newWork.updateCompleterFn() 
}() 


追踪 podWorkers 的 构造 函 BU 用 过 程 ， 可 以 发 serene 数 其 
实 束 是 kubelet 的 syncPod 方 法 ， 这 个 方法 的 代码 量 有 点 儿 多 ， 主 要 逻辑 
如 下 。 


(1) 根据 系统 配置 中 的 权限 控制 ， 检 查 Pod 是 否 有 权 在 本 市 点 运 
行 ， 这 些 权 限 包 括 Pod 是 否 有 权 使 用 HostNetwork (还 记得 之 前 分 析 的 
代码 么 ? 由 Pod Source 类 型 决定 ) 、Pod 中 的 容器 是 否 被 授权 以 特权 模 
式 启动 (privileged mode) 等 ， 如 果 未 被 授权 ， 则 删除 当前 运行 中 的 旧 
版 本 的 Pod 实 例 并 返回 错误 信息 。 


(2) 创建 Pod 相 关 的 工作 目录 、PV 存 放 目 录 、Plugin 插 件 目录 ， 
这 些 目 永 都 以 Pod 的 UID 为 上 一 级 目 永 。 


(3) 如 果 Pod 有 PV 定义 ， 则 针对 每 个 PV 执行 目录 的 mount 操 作 。 


(4) 如 果 是 SyncPodUpdate 类 型 的 Pod， 则 从 DockerRuntime 的 API 
接口 查询 获取 Pod 及 相关 容器 的 最 新 状态 信息 。 


(5) 如 果 Pod 有 imagePullSecrets 属 性 ， 则 在 API Server 上 获取 对 应 
的 Secret ° 


(6) 调用 Container Runtime 的 API 接 口 方法 SyncPod， 实 现 Pod“ 真 
正 同 步 ” 的 逻辑 。 


(7) 如 果 Pod Source 不 来 自 API Server, ， 则 继续 处 理 其 关联 的 


mirrorPod ° 


。 如 果 mirrorPod 跟 当前 Pod 的 定义 不 匹配 ， 则 它 会 被 删除 。 
。 如果 mirrorPod 还 不 存在 (比如 新 创建 的 Pod) ， 则 会 在 API Server 
上 新 建 一 个 。 


Kubernetes 中 Container Runtime 的 默认 实现 是 Dockers， 对 应 类 是 
dockertools.DockerManager ; H 源 R5 位 于 


kg/kubelet/dockertools/manager.go # , f£ LFylikubelet.syncPod7; YË "P At 
调用 的 DockerManager 的 SyncPod 方 法 实现 了 下 面 的 逻辑 。 


判断 一 个 Pod 实 例 的 哪些 组 成 部 分 需要 重启 : 包括 Pod 的 infra 容 妖 
是 否 发 生变 化 (如 网 络 模式 、Pod 里 运行 的 各 个 容器 的 端口 是 否 
发 生变 化 ) ; Pod 里 运行 的 容器 是 否 发 生变 化 用 Probe 检 测 容器 
的 状态 以 确定 容 絮 是 否 异 常 等 。 

根据 Pod 实 例 重 局 结果 的 判断 ， 如 有 果 需 要 重启 Pod 的 infra 容 右 ， 则 
$cKill Pod 然 后 启动 Pod 的 infra 容 器 ， 设 定好 网 络 ， 最 后 启动 Pod 里 
的 所 有 Container; 否则 束 移 Kil 那 些 需要 重启 的 Container， 然 后 重 
新 启动 它们 。 注 意 ， 如 果 是 新 创建 的 Pod， 则 因为 找 不 到 Node 上 
对 应 的 Pod 的 infra 容 姻 ， 所 以 会 补 当 作 重 启 Pod 的 infra 容 强 的 逻辑 
来 实现 创建 过 程 。 


DockerManager 创 建 Pod 的 infra 容 zs 的 逻辑 在 


createPodInfraContainer 方 法 里 ， 大 体 逻 辑 如 下 。 


如 条 Pod 的 网 络 不 是 HostNetwork 模 式 ， 则 搜集 Pod 所 有 容器 的 Port 
VE Nintra¥ as Pr 22k SR AY Port! Ze e 
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创建 infra 的 Container 对 象 并 且 启 动 rtnContainerInPod 方 法 。 

如 果 容 器 定义 有 Lifecycle， 并 且 PostStart 回 调 方法 被 设置 了 ， 就 会 
触发 此 方法 的 调用 ， 如 有 果 调 用 失败 则 K 记 fl 容 絮 并 返回 。 

创建 一 个 软 连接 文件 指 癌 容 颖 的 日 志文 件 ， 此 软 连 接 文 件 名 包括 
Pod 的 名 称 、 容 器 的 名 称 及 容 句 的 人 D， 这 样 的 目的 是 让 
ElasticSearch 这 样 的 搜索 技术 容易 索引 和 和 定位 Pod 日 志 。 

如 果 此 容器 是 Podinfra 容 妖 ， 则 设置 其 OOM 人 参数 低 于 标准 值 ， 使 
得 它 比 其 他 容器 具备 更 强 的 “抗灾 ”能 力 。 


。 修改 Docker 生 成 的 容器 的 resolv.conf 文 件 ， 增 加 ndots 参 数 并 默认 设 
置 为 5， 这 是 因为 Kubernetes 默 认 假 设 的 域名 分 割 长 度 是 5， 例 如 
_dns._udp.kube-dns.default.svc ° 


上 上述 逻辑 中 所 调用 的 runContainerInPod 是 DockerManager 的 核心 方 
法 之 一 ， 不 管 是 创建 Pod 的 infra 容 器 还 是 Pod 里 的 其 他 容 右 ， 都 会 通过 
此 方法 使 得 容器 被 创建 和 运行 。 以 下 是 其 主要 逻辑 。 


。 生成 Container 必 要 的 环境 变量 和 参数 ， 比 如 ENV 环 境 变 量 、 
Volume Mounts 人 信息、 端口 映 喘 信息 、DNS 服 务 器 信息 、 容 句 的 日 
志 有 日 录 、parent cgGroup 等 。 

。 调用 runContainer 方 法 完成 Docker Container 实 例 的 创建 过 程 ， 简 单 

Hin, Wæ Se Docker create container 命 令 行 所 需 的 各 种 参数 的 

构造 过 程 ， 并 通过 程序 来 调用 执行 。 

构造 HostConfig 对 象 ， 主 要 参数 有 目录 映射 、 端 口 映 射 等 、 

cgGroup 的 设 定 等 ， 简 单 地 说 ， 职 是 完成 了 Docker start container 命 

令 行 所 需 的 必要 参数 的 构造 过 程 ， 并 通过 程序 来 调用 执行 。 


在 上 述 逻 辑 中 ，runContainer 与 startContainer 的 具体 实现 都 是 靠 
DockerManager 中 的 dockerClient 对 象 完 成 的 ， 它 实现 了 DockerInterface 
接口 ，dockerClient 的 创建 过 程 在 pkg/kubelet/dockertools/docker.go 里 ， 
下 面 是 这 段 代 码 : 


func ConnectToDockerOrDie(dockerEndpoint string) 


DockerInterface { 
if dockerEndpoint == "fake://" { 
return &FakeDockerClient{ 


VersionInfo: 


docker.Env{"ApiVersion=1.18"}, 
} 


client, err "ems 
docker.NewClient(getDockerEndpoint(dockerEndpoint)) 
if err != nil { 
glog.Fatalf("Couldn't connect to docker: 
%v", err) 
} 


return client 


这 里 的 dockerEndpoint 是 本 和 点 上 的 Docker Deamon 进 程 的 访问 地 
址 ， 默 认 是 unix: ///var/run/docker.sock， 在 上 述 代码 中 使 用 了 来 自 开 源 
项 目 https://github.com/fsouza/go-dockerclient 提 供 的 Docker Client， 它 也 
是 Go 语言 实现 的 一 个 用 HTTP 访 问 Docker Deamon 提 供 的 标准 API 的 客 
PINEZ ° 


我 们 来 看 看 dockerClient 8| @ A a Hy A ARB 


(CreateContainer) 


» 


func (c *Client ) CreateContainer (opts 


CreateContainerOptions) (*Container, error) { 


path := "/containers/create " + queryString(opts) 
body, status, err := c.do( 
"POST", 


path, 


doOptions{ 
data: struct { 
*Config 
HostConfig *HostConfig 
“json: "HostConfig, omitempty" yaml:"HostConfig,omitempty"' 
TE 
opts.Config, 
opts.HostConfig, 
ty 
ty 


) 
if status == http.StatusNotFound { 


return nil, ErrNoSuchImage 


} 
if err != nil { 

return nil, err 
} 


var container Container 
err = json.Unmarshal(body, &container) 
if err != nil { 
return nil, err 
} 
container.Name = opts.Name 


return &container, nil 


的 ， 


上 述 代 码 其 实 束 是 通过 调用 标准 的 Docker RestAPI 来 实现 功能 
我 们 进入 dockerClient 的 do 方法 里 可 以 看 到 更 多 详情 ， 例 如 输入 参 


数 转 换 为 JSON 格 式 的 数据 、DockerAPI 版 本 检查 及 异常 处 理 等 逻辑 ， 
最 有 趣 的 是 : 在 dockerEndpoint 是 unix 赛 接 字 的 情况 下 ， 会 先 建立 套 接 
字 连 接 ， 然 后 在 这 个 连接 上 创建 HTTP 连接 。 


至 此 ， 我 们 分 析 了 kubelet 创 建 和 同步 Pod 实 例 的 整个 流程 ， 人 简单 总 


细则 下 


Na 


汇总 : 先 将 多 个 Pod Source 上 过 来 的 PodUpdate 事 件 汇 聚 到 一 个 总 
的 Channel 上 去 。 
初审 :分析 并 过 滤 挥 不 符合 本 节点 的 PodUpdate 事 件 ， 对 满足 条 件 
的 PodUpdate 则 生成 一 个 workUpdate 事 件 ， 交 给 podWorkers 处 理 。 
接待 : podWorkers 对 每 个 Pod 的 workUpdate 事 件 排队 ， 并 且 负 责 
新 Cache 中 的 Pod 状 态 ， 而 把 具体 的 任务 转 给 kubelet 去 处 理 
(syncPod 方 法 ) 
终审 : kubelet 对 符合 条 件 的 Pod 进 一 步 审查 ， 例 如 检查 Pod 是 否 有 
权 在 本 节点 运行 ， 对 符合 审查 的 Pod 开 始 着 手 准 备 工 作 ， 包 括 目 
录 创 建 、PV 创 建 、Image 获 取 、 处 理 Mirror Pod 问 题 等 ， 然 后 
把 “皮球 ” 踊 给 了 DockerManager ° 
落地 : 任务 抵达 DockerManager 之 后 ，DockerManager 尽 心 尽 贡 地 
分 析 每 个 Pod 的 情况 ， 以 决定 这 个 Pod 究 况 是 新 建 、 完 全 重启 还 是 
部 分 更 新 的 。 给 出 分 析 结 采 以 后 ， 和 独 下 的 就 是 dockerClient 的 工作 
了 o 


好 复杂 的 设计 ! 原来 非 业务 流程 的 代码 理解 起 来 也 会 如 此 折磨 
真心 不 知道 谷歌 当初 是 怎么 设计 和 实现 它 的 ， 目 测 国内 P8 水 平 的 


一 帮 大 牛 们 天 天 加 班 到 9 点 钟 ， 也 难以 交付 这 样 的 Code 。 


在 继续 下 面 的 分 析 之 前 ， 留 一 个 小 小 的 思考 给 聪明 的 读者 : Pod 
Source 上 发 来 的 Pod 删 除 的 事件 ， 是 在 哪里 处 理 的 ? 


接 下 来 我 们 继续 分 析 kubelet 进 程 的 另外 一 个 重要 功能 是 如 何 实现 
的 ， 即 定期 同步 Pod 状 态 信 息 到 API Server 上 。 先 来 看 看 Pod 状 态 的 数 
据 结 构 定 义 : 


type PodStatus struct { 
Phase PodPhase “json: "phase, omitempty"- 
Conditions []PodCondition 
`json: "conditions, omitempty" ` 
Message string `json:"message,omitempty"` 
Reason string ~json:"reason, omitempty"~ 
HostIP string ~json:"hostIP, omitempty"~ 
PodIP string '^json:"podIP,omitempty"' 
StartTime *util.Time '^json:"startTime,omitempty"' 
ContainerStatuses []ContainerStatus 
} 
// PodStatusResult is a wrapper for PodStatus returned 
by kubelet that can be encode/decoded 
type PodStatusResult struct { 
TypeMeta *json:",inline"~ 
ObjectMeta '^json:"metadata, omitempty" 


Status PodStatus '^json:"status,omitempty"" 


中 

( PodPending ) 、 正 常 终止 ( PodSucceeded ) ^ 5e ?$ f IE 

(PodFailed) 及 未 知 状态 (PodUnknown) ， 最 后 一 种 状态 很 可 能 是 

由 于 Pod 所 在 主机 的 通信 问题 导致 的 。 从 上 面 的 定义 可 以 看 到 Pod 的 状 

态 同 时 包括 它 里 面 运行 的 Container 的 状态 ， 另 外 给 出 了 导致 当前 状态 

的 原因 说 明 、Pod 的 启动 时 间 等 信息 。PodStatusResult 则 是 Kubernete 
API Server 提 供 的 Pod Status API 接 口中 用 到 的 Wrapper 类 。 


Pod 的 状态 (Phase) 有 5 种 : 运行 中 (PodRunning) 、 等 待 


通过 之 前 的 代码 研读 ， 我 们 发 现在 Kubernetes 中 大 量 使 用 了 
Channel 和 协 程 机 制 来 完成 数据 的 高 效 传递 和 处 理工 作 ， 在 kubelet 中 更 
是 大 量 使 用 了 这 一 机 制 ， 实 现 PodStatus 上 报 的 kubelet.statusManager 也 
是 如 此 ， 它 用 一 个 Map (podStatuses) 保存 了 当前 kubelet 中 所 有 Pod 实 
例 的 当前 状态 ， 并 且 声 明了 一 个 Channel (podStatusChannel) 来 存放 
Pod 状 态 同步 的 更 新 请 求 (podStatuses) ，Pod 在 本 地 实例 化 和 同步 的 
过 程 中 会 引发 Pod 状 态 的 变化 ， 这 些 变 化 被 封装 为 
podStatusSyncRequest 放 入 Channel 中 ， 然 后 被 异步 上 报到 API Server, 
这 就 是 statusManager 的 运行 机 制 。 


下 面 是 statusManager 的 SetPodStatus 方 法 ， 先 比较 缓存 的 状态 信 
息 ， 如 果 状 态 发 生变 化 ， 则 触发 Pod 状 态 ， 生 成 podStatusSyncRequest 
并 放 到 队列 中 等 每 上 报 : 


func (s *statusManager) SetPodStatus(pod *api.Pod, 
status api.PodStatus) { 

podFullName := kubecontainer.GetPodFullName(pod) 

s.podStatusesLock.Lock() 


defer s.podStatusesLock.Unlock() 


oldStatus, found := s.podStatuses[podFullName | 
// ensure that the start time does not change 
across updates. 
if found && oldStatus.StartTime != nil { 
status.StartTime = oldStatus.StartTime 
} 
if status.StartTime.IsZero() { 
if pod.Status.StartTime.IsZero() { 
// the pod did not have a 
previously recorded value so set to now 
now := util.Now() 
status.StartTime = &now 
) else { 
status.StartTime - 
pod.Status.StartTime 
} 
} 
if !found || !isStatusEqual(&oldStatus, &status) { 
s.podStatuses[podFullName] = status 
s.podStatusChannel <- 
podStatusSyncRequest{pod, status} 
) else ( 
glog.V(3).Infof("Ignoring same status for 
pod %q, status: 96* V", kubeletUtil.FormatPodName(pod), 


status) 


下 面 是 在 Pod 实 例 化 的 过 程 中 ，kubelet 过 滤 掉 不 合适 本 节点 Pod 所 
调用 的 上 述 方 法 的 代码 ， 类 似 的 调用 还 有 不 少 : 


func (kl  *Kubelet)  handleNotFittingPods(pods 
[]*api.Pod) []*api.Pod ( 
fitting, notFitting :- checkHostPortConflicts(pods) 
for _, pod := range notFitting { 
reason :- "HostPortConflict" 
kl.recorder.Eventf(pod, reason, "Cannot 
start the pod due to host port conflict.") 
kl.statusManager.SetPodStatus(pod, 
api.PodStatus{ 
Phase: api.PodFailed, 
Reason: reason, 
Message: "Pod cannot be started due 
to host port conflict"}) 
} 
fitting, NotFitting = 
kl.checkNodeSelectorMatching(fitting) 
for _, pod := range notFitting ( 
reason :- "NodeSelectorMismatching" 
kl.recorder.Eventf(pod, reason, "Cannot 
start the pod due to node selector mismatch.") 
kl.statusManager.SetPodStatus(pod, 
api.PodStatus{ 


Phase: api.PodFailed, 


Reason: reason, 
Message: "Pod cannot be started due 
to node selector mismatch"}) 
} 
fitting, notFitting = 
k1.checkCapacityExceeded( fitting) 
for _, pod := range notFitting { 
reason := "CapacityExceeded" 
kl.recorder.Eventf(pod, reason, "Cannot 
start the pod due to exceeded capacity.") 
kl.statusManager.SetPodStatus(pod, 
api.PodStatus( 
Phase: api.PodFailed, 
Reason: reason, 
Message: "Pod cannot be started due 
to exceeded capacity") 


j 


return fitting 


最 后 ， 我 们 看 看 statusManager 是 怎么 把 Channel 的 数据 上 报到 API 
Server 上 的 ， 这 是 通过 Start 方 法 开启 一 个 协 程 无 限 循环 执行 syncBatch 
方法 来 实现 的 ， 下 面 是 syncBatch 的 代码 : 


func (s *statusManager) syncBatch() error { 
syncRequest := <-s.podStatusChannel 


pod := syncRequest.pod 


podFullName := kubecontainer.GetPodFullName(pod) 


status :- syncRequest.status 


var err error 
statusPod :- &api.Pod{ 


ObjectMeta: pod.ObjectMeta, 


statusPod, err - 
s.kubeClient.Pods(statusPod.Namespace).Get(statusPod.Name) 
if err == nil { 
statusPod.Status = status 
=} err = 
s.kubeClient.Pods(pod.Namespace).UpdateStatus(statusPod) 
// TODO: handle conflict as a retry, make 
that easier too. 
if err == nil { 
glog.V(3).Infof("Status for pod %q 
updated successfully", kubeletUtil.FormatPodName(pod) ) 


return nil 


} 
go s.DeletePodStatus(podFullName) 


return fmt.Errorf("error updating status for pod 


?60: 96v", kubeletUtil.FormatPodName(pod), err) 
} 


这 段 代 码 首 先 从 Channel 中 拉 取 一 个 syncRequest， 然 后 调用 API 
Server 接 口 来 获取 最 新 的 Pod 信 息 ， 如 有 果 成 功 ， 则 继续 调用 API Server 
的 UpdateStatus 接 口 更 新 Pod 状 态 ， 如 果 调 用 失败 则 删除 缓存 的 Pod 状 
态 ， 这 将 触发 kubelet 重 新 计算 Pod 状 态 并 再 次 尝试 更 新 。 


说 完了 Pod 流 程 ， 我 们 接 下 来 再 一 起 深入 分 析 Kubernetes 中 的 容器 
探 针 (Probe) 的 实现 机 制 。 我 们 知道 ， 容 器 正常 不 代表 里 面 运行 的 业 
务 进程 能 正常 工作 ， 比 如 程序 还 没 初始 化 好 ， 或 者 配置 文件 错误 导致 
无 法 正常 服务 ， 还 有 诸如 数据 库 连 接 爆 满 导致 服务 异常 等 各 种 意外 情 
况 都 有 可 能 发 生 ， 面 对 这 类 问题 ，cAdvisor 束 束手无策 了 ， 所 以 
kubelet 引 入 了 容 事 探 针 技 术 ， 容 器 探 针 按 照 作 用 划分 为 以 下 两 种 。 


e ReadinessProbe: 用 来 探测 容器 中 的 用 户 服 务 进 程 是 否 处 于 “可 服 
务 状 态 ”， 此 探 针 不 会 导致 容 喜 被 停止 或 重 局， 而 是 导致 此 容 丹 上 
的 服务 被 标识 为 不 可 用 ，Kubernetes 不 会 发 送 请 求 到 不 可 用 的 容 
器 上 ， 直 到 它们 可 用 为 止 。 

LivenessProbe: 用 来 探测 容器 服务 是 否 处 于 “存活 状态 ”， 如 有 果 服 
务 当前 被 检测 为 Dead， 则 会 导致 容 央 重 局 事件 发 生 。 


下 面 古 探 针 相关 的 结构 定义 : 


type Probe struct { 
Handler 
InitialDelaySeconds int64 
TimeoutSeconds int64 

} 

type Handler struct { 


// One and only one of the following should be 


specified. 
Exec *ExecAction 
HTTPGet *HTTPGetAction 


TCPSocket *TCPSocketAction 


j 
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正常 工作 。 
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pkg/kubelet/proberprober go 里 ， 下 面 是 对 prober.Probe 的 定义 : 


type Prober interface { 
Probe(pod *api.Pod, status api.PodStatus, container 
api.Container, containerID string, createdAt int64) 


(probe.Result, error) 


} 
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prober.Probe 的 实现 类 为 prober.prober， 其 结构 定义 如 下 : 


type prober struct { 
exec execprobe.ExecProber 
http httprobe.HTTPProber 


tcp tcprobe.TCPProber 


runner kubecontainer .ContainerCommandRunner 
readinessManager *kubecontainer .ReadinessManager 
refManager *kubecontainer .RefManager 


recorder record.EventRecorder 


其 中 exec、http、tcp 三 个 变量 分 别 对 应 三 种 探测 类 型 的 < 探头”， 它 
们 已 经 各 自 实现 了 相应 的 逻辑 。 比 如 下 面 这 段 代码 是 HTTP 探 头 的 核心 
逻辑 ， 即 连接 一 个 URL 发 起 GET 请 求 : 


func DoHTTPProbe(url *url.URL, client 
HTTPGetInterface) (probe.Result, string, error) { 
res, err :- client.Get(url.String()) 
if err != nil ( 
// Convert errors into failures to catch 
timeouts. 
return probe.Failure, err.Error(), nil 
} 
defer res.Body.Close() 
b, err :- ioutil.ReadAll(res.Body) 
if err != nil ( 
return probe.Failure, "", err 
} 
body := string(b) 
if res.StatusCode >= http.StatusOK  && 
res.StatusCode < http.StatusBadRequest { 


glog.V(4).Infof("Probe succeeded for %s, 


Response: %v", url.String(), *res) 


return probe.Success, body, nil 


glog.V(4).Infof("Probe failed for %s, Response: 
9€$v", url.String(), *res) 


return probe.Failure, body, nil 


prober.prober 中 的 runner 则 是 exec 探 尖 的 执行 器 ， 因 为 后 者 需要 在 
被 检 测 的 容器 中 执行 一 个 cmd 命 令 : 


func (p *prober) newExecInContainer(pod *api.Pod, 
container api.Container, containerID string, cmd []string) 
exec.Cmd { 
return execInContainer{func() ([]byte, error) { 
return p.runner.RuninContainer(containerID, 


cmd) 
}} 


实际 上 p.runner 束 是 之 前 我 们 分 析 过 的 DockerManager， 下 面 是 
RunInContainer 的 源码 : 


func (dm *DockerManager) RuninContainer(containerID 
string, cmd []string) ([]byte, error) { 
// If native exec support does not exist in the 


local docker daemon use nsinit. 


useNativeExec, err := dm.nativeExecSupportExists() 
if err != nil ( 
return nil, err 
} 
if !useNativeExec { 
glog.V(2).Infof("Using nsinit to run the 
command %+v inside container %s", cmd, containerID) 
return 
dm. runInContainerUsingNsinit(containerID, cmd) 
} 
glog.V(2).Infof("Using docker native exec to run 


cmd %+v inside container %s", cmd, containerID) 


createOpts := docker.CreateExecOptions{ 
Container: containerID, 
Cmd: cmd, 


AttachStdin: false, 
AttachStdout: true, 


AttachStderr: true, 


Tty: false, 
} 
execObj, err := dm.client.CreateExec(createOpts) 
if err != nil ( 


return nil, fmt.Errorf("failed to run in 
container - Exec setup failed - %v", err) 
} 
var buf bytes.Buffer 


startOpts := docker.StartExecOptionst{ 


Detach: false, 
Tty: false, 
OutputStream: &buf, 
ErrorStream:  &buf, 
RawTerminal: false, 
} 
err = dm.client.StartExec(execObj.ID, startOpts) 
if err != nil { 
glog.V(2).Infof("StartExec With error: %v", 
err) 
return nil, err 
} 
ticker := time.NewTicker(2 * time.Second) 
defer ticker.Stop() 
for { 
inspect, err2 : = 
dm.client.InspectExec(execObj.ID) 
if err2 != nil { 
glog.V(2).Infof("InspectExec %s failed 
with error: %+tv", execObj.ID, err2) 
return buf.Bytes(), err2 
} 
if !inspect.Running { 
if inspect.ExitCode != 0 { 
glog.V(2).Infof("InspectExec %s exit 
with result %+v", execObj.ID, inspect) 


err = &dockerExitError{inspect } 


break 


«-ticker.C 


return buf.Bytes(), err 


Docker 自 1.3 版 本 开始 支持 使 用 Exec 指 令 (以 及 API 调 用 ) 在 容器 
内 执行 一 个 命令 ， 我 们 看 看 上 述 过 程 中 使 用 的 dm.client.CreateExec 方 
法 是 如 何 实现 的 : 


func (c *Client) CreateExec(opts CreateExecOptions) 
(*Exec, error) ( 
path := fmt.Sprintf("/containers/%s/exec", 
opts.Container) 
body, status, err := c.do("POST", path, 
doOptions{data: opts}) 
if status == http.StatusNotFound { 
return nil, &NoSuchContainer{ID: 


opts.Container } 


} 
if err != nil { 

return nil, err 
} 


var exec Exec 


err = json.Unmarshal(body, &exec) 
if err != nil { 
return nil, err 


j 


return &exec, nil 


我 们 看 到 ， 这 是 标准 的 Docker API 的 调用 方式 ， 跟 之 前 看 到 的 创 
建 容 絮 的 调用 代码 很 相似 。 现 在 我 们 再 回头 看 看 prober.prober 是 怎么 执 
行 ReadinessProbe/LivenessProbe 的 检测 逻辑 的 : 


func (pb *prober) Probe(pod *api.Pod, status 
api.PodStatus, container api.Container, containerID string, 
createdAt int64) (probe.Result, error) { 
pb.probeReadiness(pod, status, container, 
containerID, createdAt ) 
return pb.probeLiveness(pod, status, container, 
containerID, createdAt ) 


j 


这 上段 代码 先 调 用 容器 的 ReadinessProbe 3# 47 f$ JU, Ft H TE 
readinessManager?H fF FP id 3 ait HY Readiness 1A, Baa val A A as HJ 
LivenessProbe 进 行 检 测 ， 并 返回 容 需 的 状态 ， 在 检测 过 程 中 如 果 发 现 
状态 为 失败 或 者 异常 状态 ， 则 会 连续 检测 3 次 : 


func (pb *prober) runProbeWithRetries(p *api.Probe, 


pod *api.Pod, status api.PodStatus, container 


api.Container, containerID string, retries int) 
(probe.Result, string, error) ( 

var err error 

var result probe.Result 

var output string 

for i := 0; i < retries; i++ { 

result, output, err = pb.runProbe(p, pod, 
status, container, containerID) 
if result == probe.Success { 


return probe.Success, output, nil 


j 


return result, output, err 


比较 意外 的 是 proberprober 探 针 检 测 容器 状态 的 方法 目前 只 在 一 处 
被 调用 到 ， 位 于 方法 DockerManagercomputePodContainerChanges 里 : 


result, err := dm.prober.Probe(pod, podStatus, 
container, string(c.ID), c.Created) 
if err != nil { 
// TODO(vmarmol): examine this 
logic. 
glog.V(2).Infof("probe no-error: 
%q", container.Name) 
containersToKeep[containerID] - 


index 


continue 
} 
if result == probe.Success { 
glog.V(4).Infof("probe success: 
%q", container .Name) 
containersToKeep[containerID] = 
index 


continue 


glog.Infof("pod %q container %q is 
unhealthy (probe result: %v), it will be killed and re- 
created.", podFullName, container.Name, result) 


containersToStart[index] = empty{} 
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态 为 失败 ， 则 会 导致 重 局 事件 发 生 。 


本 蔬 最 后 ， 我 们 再 来 简单 分 析 下 kubelet 中 的 Kubelet Server 的 实现 
机 制 ， 下 面 是 kubeletj 井 程 局 动 过 程 中 启动 Kubelet Server 的 源码 入 口 : 


// start the kubelet server 
if kc.EnableServer { 
go util.Forever(func() { 
k.ListenAndServe(net.IP(kc.Address), 


kc.Port, kc.TLSOptions, kc.EnableDebuggingHandlers) 


t, 9) 
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HTTP Server 并 在 本 地 监听 : 


handler := NewServer(host, enableDebuggingHandlers) 
S := &http.Server( 
Addr: 
net.JoinHostPort(address.String(), 


strconv.FormatUint(uint64(port), 10)), 


Handler: &handler, 
ReadTimeout: 5 * time.Minute, 
WriteTimeout: 5 * time.Minute, 


MaxHeaderBytes: 1 «« 20, 
} 
if tlsOptions != nil { 


s.TLSConfig = tlsOptions.Config 


glog.Fatal(s.ListenAndServeTLS(tlsOptions.CertFile, 
tlsOptions.KeyFile) ) 
) else { 


glog.Fatal(s.ListenAndServe()) 


在 kubelet.Server 的 构造 函数 里 加 载 如 下 HTTP Handler: 


func (s *Server) InstallDefaultHandlers() { 
healthz.InstallHandler(s.mux, 
healthz.PingHealthz, 
healthz.NamedCheck("docker", 
s.dockerHealthCheck), 
healthz.NamedCheck("hostname", 
s.hostnameHealthCheck), 
healthz.NamedCheck("syncloop", 
s.syncLoopHealthCheck), 
) 
s.mux.HandleFunc("/pods", s.handlePods) 
s.mux.HandleFunc("/stats/", s.handleStats) 


s.mux.HandleFunc("/spec/", s.handleSpec) 


上 述 Handler 分 为 两 组 : 首先 是 健康 检查 ， 包 括 kubeletj 进 程 目 身 的 
心跳 检查 、Docker 进 程 的 健康 检查 、 RPEN 在 主机 名 检测 、Pod 同 步 
的 健康 检查 等 ， 然 后 是 获取 当前 节点 上 运行 期 信息 的 接口 ， 例 如 获取 
当前 万 点 上 的 Pod 列 表 、 统 计 信 息 等 。 下 面 是 hostnameHealthCheck 的 
实现 逻辑 ， 它 检查 Pod 两 次 同步 之 间 的 时 延 ， 而 这 个 时 延 则 在 之 前 提 
到 的 kubelet 的 syncLoopIteration 方 法 中 进行 更 新 : 


func (s *Server ) syncLoopHealthCheck(req 
*http.Request) error ( 
duration :- s.host.ResyncInterval() * 2 
minDuration :- time.Minute * 5 


if duration « minDuration ( 


duration = minDuration 
} 
enterLoopTime := s.host.LatestLoopEntryTime( ) 
if !enterLoopTime.IsZero( ) && 
time.Now().After(enterLoopTime.Add(duration)) { 
return fmt.Errorf("Sync Loop took longer 
than expected.") 


j 


return nil 


handlePods 的 API 则 从 kubelet 中 获取 当前 “ 绑 定 ”到 本 和 点 的 所 有 
Pod 的 信息 并 返回 : 


func (s *Server) handlePods(w http.ResponseWriter, req 
*http.Request) { 
pods :- s.host.GetPods() 
data, err :- encodePods(pods) 
if err != nil { 
s.error(w, err) 
return 
} 
w.Header().Add("Content-type", "application/json") 


w.Write(data) 


如 果 kubelet 运 行 在 Debug 模 式 ， 则 加 载 更 多 的 HTTP Handler: 


func (s *Server) InstallDebuggingHandlers() { 
s.mux.HandleFunc("/run/", s.handleRun) 
s.mux.HandleFunc("/exec/", s.handleExec) 
s.mux.HandleFunc("/portForward/", 


s.handlePortForward) 


s.mux.HandleFunc("/logs/", s.handleLogs) 
s.mux.HandleFunc("/containerLogs/", 
s.handleContainerLogs) 
s.mux.Handle("/metrics", prometheus.Handler()) 
// The /runningpods endpoint is used for testing 
only. 
s.mux.HandleFunc("/runningpods", 


s.handleRunningPods) 


s.mux.HandleFunc("/debug/pprof/", pprof.Index) 
s.mux.HandleFunc("/debug/pprof/profile", 
pprof.Profile) 
s.mux.HandleFunc("/debug/pprof/symbol", 
pprof.Symbol) 


} 


这 些 HTTPHandler 的 实现 并 不 复杂 ， 所 以 在 这 里 就 不 再 一 一 介绍 


65.3 ”设计 总 结 


在 研读 kubelet 源 人 码 的 过 程 中 ， 你 经 常会 有 “ 山 穷 水 尽 疑 无 路 ， 柳 上 暗 
花 明 又 一 村 ”的 感觉 ， 是 因为 在 它 的 设计 中 大 量 运 用 了 Channel 这 种 异 
步 消 息 机 制 ， 加 之 为 了 测试 的 方便 ， 又 将 很 多 重要 的 处 理 函 数 做 成 接 
口 类 ， 只 有 找到 并 分 析 这 些 接口 的 具体 实现 类 ， 才 能 明日 整个 流程 。 
这 对 于 习惯 了 面向 对 象 语言 的 程序 员 而 言 ， 有 一 种 一 夜 回 到 解放 前 的 


= A 
感觉 。 


因为 kubelet 的 功能 比较 多 ， 所 以 我 们 在 此 仅 以 Pod 同 步 的 主流 程 为 
例 ， 进 行 一 个 设计 总 结 ， 图 6.8 是 kubelet 主 流程 相关 的 设计 示意 图 ， 为 
了 更 加 清晰 地 展示 整个 流程 ， 我 们 特意 将 kubelet Kernel ^ Docker 
System 与 其 他 部 分 分 离开 来 ， 并 且 省 略 了 部 分 非 核心 对 象 和 数据 结 
构 。 


首先 ，config.PodConfig 创 建 一 个 或 多 个 Pod Source， 在 默认 情况 
下 创建 的 是 API source， 它 并 没有 创建 新 的 数据 结构 ， 而 是 使 用 之 前 介 
绍 的 cache.Reflector 结 合 cache.UndeltaStore， 从 Kubernetes API Server E 
拉 取 Pod 数 据 放 入 内 部 的 Channel 上， 而 内 部 的 Channel 收 到 Pod 数 据 后 
会 调用 podStorage 的 Merge 方 法 实现 多 个 Channel 数 据 的 合并 ， 产 生 
kubelet.PodUpdate 消息 并 写 入 PodConfig 的 汇总 Channel 上 ， 随 后 
PodUpdate 消 息 进入 kubelet Kernel 中 进行 下 一 步 处 理 。 


kubelet.kubelet 的 syncLoop 方 法 监听 PodConfig 的 汇总 Channel， 过 
滤 挥 不 合适 的 PodUpdate 并 把 符合 条 件 的 放 入 SyncPods 方 法 中 ， 最 终 为 


^ E Z ffr AY Pod 7^ Œ — ^ kubelet.workUpdate 事件 并 放 入 
ME 内 部 工作 队列 上 ， 随 后 调用 podWorkers 的 managePodLoop 
方法 进行 处 理 。podWorkers 在 处 理 流程 中 调用 了 DockerManager 的 
SyncPod 方 法 ， 由 此 DockerManager 接 班 ， 在 进行 了 必要 的 Pod 周 边 操 
作 后 ， 对 于 需要 重启 或 者 更 新 的 容 右 ，DockerManager 则 交 给 
docker.Client 对 象 去 执行 具体 的 动作 ， 后 者 通过 调用 Dockers Engine’) 
API Service 来 实现 具体 功能 


在 Pod 同 步 的 过 程 中 会 产生 Pod 状 态 的 变更 和 同步 问题 ， 这 些 是 交 
由 kubelet.statusManager 实 现 的 ， 它 在 内 部 也 采用 了 Channel 的 设计 方 
式 。 


&l6.8 ”kubelet 主 流程 相关 的 设计 示意 图 


6.6 ”kube-proxy 进 程 源 人 码 分 析 


kube-proxy 是 运行 在 Minion 节 点 上 的 另外 一 个 重要 的 守护 进程 ， 
你 可 以 把 它 当 作 一 个 HAProxy， 它 充当 了 Kubernetes 中 Service 的 负载 均 
衡 希 和 服务 代理 的 角色 。 下 面 我 们 分 别 对 其 局 动 过 程 、 天 键 代码 分 析 
及 设计 总 结 等 方面 进行 深入 分 析 和 讲解 。 


6.6.1 进程 局 动 过 程 


kube-proxy 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kube- 


proxy/proxy.go 


ALHmain () 函数 的 逻辑 如 下 : 


func main() { 
runtime.GOMAXPROCS(runtime.NumCPU()) 
S := app.NewProxyServer() 


s.AddFlags(pflag.CommandLine) 


util.InitFlags() 
util.InitLogs() 
defer util.FlushLogs() 


verflag.PrintAndExitIfRequested() 


if err :- s.Run(pflag.CommandLine.Args()); err !- 
nil { 
fmt.Fprintf(os.Stderr, "%v\n", err) 


as. EXIt(1) 


上 述 代 码 构 造 了 一 个 ProxyServer， 然 后 调用 它 的 Run 方 法 局 动 运 
行 。 首 先 我 们 看 看 NewProxyServer 的 代码 : 


func NewProxyServer() *ProxyServer { 
return &ProxyServert{ 
BindAddress: 
util.IP(net.ParseIP("0.0.0.0")), 
HealthzPort: 10249, 
HealthzBindAddress: 
util. IP(net.ParseIP("127.0.0.1")), 
OOMScoreAdj: -899, 


ResourceContainer:  "/kube-proxy", 


在 上 述 代 码 中 ，ProxyServer 绑 定 本 地 所 有 IP (0.0.0.0) 对 外 提供 
代理 服务 ， 而 提供 健康 检查 的 HTTP Server 则 默认 绑 定 本 地 的 回环 IP， 
说 明 后 者 仅 用 于 在 本 和 点 上 访问 ， 如 果 需 要 开发 管理 系统 进行 远程 管 
理 ， 则 可 以 设置 参数 healthz-bind-address 为 0.0.0.0 来 达到 目的 。 另 外 ， 
从 代码 中 看 ，ProxyServer 还 有 一 个 重要 属性 可 以 调整 : PortRange (对 
应 命令 行 参数 为 proxy-port-range) ， 它 用 来 限定 ProxyServer 使 用 哪些 
本 地 端口 作为 代理 端口 ， 默 认 是 随机 选择 。 


ProxyServer 的 Run 方 法 流程 如 下 。 


设置 本 进程 的 OOM 参 数 OOMScoreAdj ， 保 证 系统 OOM 时 ，kube- 
proxy 不 会 百 先 被 系统 删除 ， 这 是 因为 kube-proxy 与 kubelet 进 程 一 
样 ， 比 节点 上 的 Pod 进 程 更 重要 e 
让 目 己 的 进程 运行 在 指定 的 Linux Container 中 ， 这 个 Container 的 名 
字 来 目 ProxyServerResourceContainer ， 如 上 上 所 述 ， 默 认为 /kube- 
proxy， 比 较 重 要 的 一 点 是 这 个 Container 具 备 所 有 设备 的 访问 权 。 
。 创建 ServiceConfig 与 EndpointsConfig ， 它 们 与 之 前 kubelet 中 的 
PodConfig 的 作用 和 实现 机 制 有 点 像 ， 分 别 负责 监听 和 拉 取 API 
Server 上 Service 与 Service Endpoints 的 信息 ， 并 通知 给 注册 到 它们 
上 的 Listener 接 口 进行 处 理 。 
创 Æ 一 个 round-robin 轮 询 机 制 的 load balancer 
(LoadBalancerRR) ， 它 用 来 实现 Service 的 负载 均衡 转发 逻辑 ， 
它 也 是 前 面 创建 的 EndpointsConfig 的 一 个 Listener ° 
创建 一 个 Proxier， 它 负责 建立 和 维护 Service 的 本 地 代理 Socket， 
它 也 是 前 面 创建 的 ServiceConfig 的 一 个 Listener ° 
创建 一 个 config.SourceAPI， 并 启动 两 个 协 程 ， 通 过 Kubernetes 
Client 来 拉 取 Kubernetes API Server 上 的 Service 与 Endpoint 数 据 ， 然 
后 分 别 写 入 之 前 定义 的 ServiceConfig 与 EndpointsConfig 的 Channel 
上 ， 从 而 触发 整个 流程 的 驱动 。 
本 地 绑 定 健康 检查 的 HITP Server 提 供 服 务 。 
进入 Proxier 的 SyncLoop 方 法 里 ， 该 方法 周期 性 地 检查 Iptables 是 否 
设置 正常 、 服 务 的 Portal 是 否 正 常 开 局 ， 以 及 清除 load balancer E 
的 过 期 会 话 。 


从 启动 流程 看 ，kube-proxy 进 程 的 参数 比较 少 ， 它 所 做 的 事情 也 
是 比较 单一 的 ， 没 有 kubelet 进 程 那 么 复杂 ， 在 下 一 市 我 们 会 深入 分 析 
其 关键 代码 。 


6.6.2 ”关键 代码 分 析 


从 上 一 和 kube-proxy 的 局 动 流程 来 看 ， 它 跟 kubelet 有 相似 的 地 
方 ， 即 都 会 从 Kubernetes API Server 拉 取 相 关 的 资源 数据 并 在 本 地 市 点 
上 完成 “深加工 >， 其 拉 取 资源 的 做 法 ， 第 一 眼看 上 去 与 kubelet 相 似 ， 
但 实际 上 有 稍微 不 同 的 实现 思路 ， 这 说 明 作 者 男 有 其 人 。 


由 于 ServiceConfig 与 EndpointsConfig 实 现 机 制 是 完全 一 样 的 ， 只 
不 过 拉 取 的 资源 不 同 ， 所 以 我 们 这 里 仅 对 前 者 做 深入 分 析 。 首 先 从 
ServiceConfig 结 构 体 开始 : 


type ServiceConfig struct { 
mux *config.Mux 
bcaster *config.Broadcaster 


store *serviceStore 


ServiceConfig 也 使 用 了 mux (config.Mux) ， 它 是 一 个 多 Channel 
Hy 2 A as, Z Hil kubelet 的 PodConfig 也 用 到 了 它 。 下 面 是 
ServiceConfig 的 构造 函数 : 


func NewServiceConfig() *ServiceConfig { 
updates := make(chan struct{}) 
store := &serviceStore{updates: updates, services: 


make(map[string]map[types.NamespacedName ]api.Service) } 


mux := config.NewMux(store) 
bcaster := config.NewBroadcaster() 
go watchForUpdates(bcaster, store, updates) 


return &ServiceConfig{mux, bcaster, store} 


M ERRE, store Æ serviceStore 的 一 个 实例 。 它 作为 
config.Mux 的 Merge 接 口 的 实现 ， 负 责 处 理 config.Mux 的 ee 
HJ ServiceUpdate 7H E 2f 5E Xr store HY A ab Æ Œ services, Ja aE — 
Map, ， 存 放 了 最 新 同步 到 本 地 的 api.Service 资 源 ， 是 Service 的 全 量 数 
据 。 下 面 是 Merge 方 法 的 逻辑 : 


func (s *serviceStore) Merge(source string, change 
interface{}) error { 
s.serviceLock.Lock() 
services := s.services[source ] 
if services == nil { 
services = 
make(map[types.NamespacedName ]api.Service) 
} 
update := change. (ServiceUpdate) 
switch update.Op { 
case ADD: 
glog.V(4).Infof("Adding new service from 
source 96s : 96*v", source, update.Services) 
for , value := range update.Services { 


name :二 


types .NamespacedName{value.Namespace, value.Name} 
services[name] = value 
} 
case REMOVE: 
glog.V(4).Infof("Removing a service %tv", 
update) 
for _, value := range update.Services { 
name := 
types .NamespacedName{value.Namespace, value.Name} 
delete(services, name) 
} 
case SET: 
glog.V(4).Infof("Setting services %+v", 
update) 
// Clear the old map entries by just 


creating a new map 


services - 
make (map[types.NamespacedName ]api.Service) 
for , value := range update.Services { 
name E 


types .NamespacedName{value.Namespace, value.Name} 


services[name] = value 


default: 
glog.V(4).Infof("Received invalid update 
type: %v", update) 
} 


s.services[source] = services 
s.serviceLock.Unlock( ) 
if s.updates != nil { 

s.updates <- struct{}{} 
} 


return nil 


serviceStore 同 时 是 config.Accessor 接 口 的 一 个 实现 ，MergedState 接 
口 方法 返回 之 前 Merge 最 新 的 Service 全 量 数 据 。 


func (s *serviceStore) MergedState() interface{} { 
s.serviceLock.RLock( ) 


defer s.serviceLock.RUnlock( ) 


services := make([]api.Service, 0) 
for _, sourceServices := range s.services { 
for _, value := range sourceServices { 


services = append(services, value) 


j 


return services 


Et 7; YETEWD RS RESI p We? LE ZB He Bl HY NewServiceConfig 
方法 里 : 


go watchForUpdates(bcaster, store, updates) 


一 个 协 程 监听 serviceStore 的 updates (Channel) ， 在 收 到 事件 以 后 
束 调 用 上 述 MergedState 方 法 ， 将 当前 最 新 的 Service 数 组 通知 注册 到 
bcaster 上 的 所 有 Listenerj 进 行 处 理 。 下 面 分 别 给 出 了 watchForUpdates 及 
Broadcaster 的 Notify 方 法 的 源码 : 


func watchForUpdates(bcaster *config.Broadcaster, 
accessor config.Accessor, updates <-chan struct{}) { 
for true { 
<-updates 


bcaster.Notify(accessor.MergedState( )) 


j 


func (b *Broadcaster) Notify(instance interface{}) { 
b.listenerLock.RLock( ) 
listeners :- b.listeners 
b.listenerLock.RUnlock() 
for , listener :- range listeners ( 


listener.OnUpdate(instance) 


上 述 逻 辑 的 精巧 设计 之 处 在 于 ， 当 ServiceConfig 完 成 Merge 调 用 
后 ， 为 了 及 时 通知 Listener 进 行 处 理 ， 就 产生 一 个 “ 空 事件 ”并 写 入 
updates 这 个 Channel 中 ， 另 外 监听 此 Channel 的 协 程 束 及 时 得 到 通知 ， 
触发 Listener 的 回调 动作 。 ServiceConfig 这 里 注册 的 Listener 是 
proxy.Proxier 对 象 ， 我 们 以 后 会 继续 分 析 它 的 回调 函数 OnUpdate 是 如 
何 使 用 Service 数 据 的 。 


接 下 来 ， 我 们 看 看 ServiceUpdate 事 件 是 怎么 生成 并 传递 到 
ServiceConfig 的 Channel 上 的 。 在 kube-proxy 局 动 流程 中 有 调用 
config.NewSourceAPI 函 数 ， 其 内 部 生成 了 一 个 servicesReflector 对 象 : 


type servicesReflector struct { 
watcher ServicesWatcher 
services chan<- ServiceUpdate 
resourceVersion string 
waitDuration time.Duration 


reconnectDuration time.Duration 


H H servicesixX “+ Channel ze Fl X 5j A ServiceUpdate # TER, "E x 
ServiceConfig 的 Channel (source string) 方法 所 创建 并 返回 的 
Channel， 它 写 入 数据 后 束 会 被 一 个 协 程 立即 转发 到 ServiceConfig 的 
Channel 里 。 下 面 这 上 段 代 码 完整 地 揭示 了 上 壕 逻 辑 : 


func (c *ServiceConfig) Channel(source string) chan 
ServiceUpdate { 
ch := c.mux.Channel(source) 
serviceCh := make(chan ServiceUpdate) 
go func() { 
for update := range serviceCh { 
ch <- update 
} 
close(ch) 


3() 


return serviceCh 


servicesReflector 中 的 watcher H ?& A, API Server E fiz AX Service 数 
$8 . © 是 clientServices ( apiNamespaceAll ) jk [Al AY 
client.ServiceInterface 实 例 对 象 的 一 个 引用 ， 属 于 标准 的 Kubernetes 
client 包 。 在 config.NewSourceAPI 的 方法 里 ， 启 动 了 一 个 协 程 周期 性 地 
调用 watcher 的 list 与 Watch 方法 获取 数据 ， 然 后 转换 成 ServiceUpdate 事 
件 ， 写 入 Channel 中 。 下 面 是 关键 源码 : 


func (s *servicesReflector) run(resourceVersion 
*string) { 
if len(*resourceVersion) == 0 { 
services, err = 
s.watcher.List(labels.Everything()) 
if err != nil { 
glog.Errorf("Unable to load 
services: %v", err) 
// TODO: reconcile with 


pkg/client/cache which doesn't use reflector. 


time.Sleep(wait.Jitter(s.waitDuration, 0.0)) 
return 
} 
*resourceVersion = services.ResourceVersion 
// TODO: replace with code to update the 


s.services <- ServiceUpdate{Op: SET, 


Services: services.Items} 
} 
watcher, err := 
s.watcher.Watch(labels.Everything(), fields.Everything(), 
*resourceVersion) 
if err != nil ( 
glog.Errorf("Unable to watch for services 
changes: %v", err) 
if !client.IsTimeout(err) { 
// Reset so that we do a fresh get 
request 


*resourceVersion - "" 


time.Sleep(wait.Jitter(s.waitDuration, 
0.0)) 
return 
} 
defer watcher.Stop() 
ch := watcher .ResultChan() 


s.watchHandler(resourceVersion, ch, s.services) 


在 上 面 的 代码 中 ， 初 始 时 资源 版 本 变量 resourceVersion 为 空 ， 于 是 
会 执行 Service 的 全 量 拉 取 动作 (watcher.List) ， 之 后 Watch 资源 会 开始 
发 生变 化 (watcher.Watch) 并 将 Watch 的 结果 (一 个 Channel 保 持 了 
Service 的 变动 数据 ) 也 转换 为 对 应 的 ServiceUpdate 事 件 并 写 入 Channel 
中 。 另 外 ， 当 拉 取 数据 的 调用 发 生 有 异常 时 ，resourceVersion 恢 复 为 空 ， 


导致 重新 进行 全 量 资源 的 拉 取 动作 。 这 种 自修 复 能 力 的 编程 设计 足以 
见证 谷歌 大 神 们 的 深厚 编程 功力 ; 另外 ， 笔 者 认为 kube-proxy 这 里 的 
ServiceConfig 的 设计 实现 思路 和 代码 要 比 kubelet 中 的 好 一 点 ， 虽 然 两 
个 作者 都 是 顶尖 高 


接 下 来 才 开 始 进 入 本 市 的 重点 ， 即 服务 代理 的 实现 机 制 分 析 。 首 
先 ， 我 们 从 代码 中 的 load balance 组 件 说 起 。 下 面 是 kube-proxy 中 定义 
的 LoadBalancer 接 口 : 


type LoadBalancer interface { 
NextEndpoint(service ServicePortName, srcAddr 
net.Addr) (string, error) 

NewService(service | ServicePortName, 
sessionAffinityType api.ServiceAffinity, 
stickyMaxAgeMinutes int) error 

CleanupStaleStickySessions(service ServicePortName) 


} 


LoadBalancer 有 3 个 接口 ， 其 中 NextEndpoint 方 法 用 于 给 访问 指定 
Service 的 新 客户 端 请 求 分 配 一 个 可 用 的 Endpoint 地 址 ; NewService 用 
来 添加 一 个 新 服务 到 负载 均衡 右上 ; CleanupStaleStickySessions 则 用 来 
清理 过 期 的 Session 会 话 。 目 前 kube-proxy 只 实现 了 一 个 基于 round-robin 
算法 的 负载 均衡 右 ， 它 了 驶 是 proxy.LoadBalancerRR 组 件 。 


LoadBalancerRR 采 用 了 affinityState 这 个 结构 体 来 保存 当前 客户 端 
的 会 话 信 息 ， 然 后 在 affinityPolicy 里 用 一 个 Map 来 记录 (属于 某 个 
Service 的 ) 所 有 活动 的 客户 端 会 话 ， 这 是 它 实现 Session 亲 和 人 性 的 负载 
均衡 调度 的 基础 。 


type affinityState struct { 
clientIP string 
//clientProtocol api.Protocol //not yet used 
//sessionCookie string //not yet used 
endpoint string 
lastUsed time.Time 
} 
type affinityPolicy struct { 
affinityType api.ServiceAffinity 
affinityMap map[string]*affinityState // map 
client IP -> affinity info 


ttlMinutes int 


balancerState Hi 2E iD R — A Service] Pr £j Endpoint (2028) 、 当 前 
所 使 用 的 Endpoint 的 index， 以 及 对 应 的 所 有 活动 的 客户 端 会 话 
(affinityPolicy) 。 其 定义 如 下 : 


type balancerState struct { 
endpoints []string // a list of "ip:port" style 
strings 
index int // current index into endpoints 


affinity affinityPolicy 


^ I EMU, FA LoadBalancerRRAY (ie KA al AS T, 
它 内 部 用 一 个 map 记 录 每 个 服务 的 balancerState 状 态 ， 当 然 初 始 化 时 还 


func NewLoadBalancerRR() *LoadBalancerRR { 
return &LoadBalancerRR{ 
services: 


map [ServicePortName]*balancerState(], 


j 


LoadBalancerRR 的 NewService 方 法 代码 很 简单 ， 就 是 在 它 的 
services 里 增加 一 个 记录 项 ， 用 户 端 的 会 话 超时 时 间 tMinutes 默 认为 3 
小 时 ， 下 面 是 相关 源码 : 


func (lb  *LoadBalancerRR)  NewService(svcPort 
ServicePortName, affinityType api.ServiceAffinity, 
ttlMinutes int) error ( 
lb.lock.Lock() 
defer lb.lock.Unlock() 
lb.newServiceInternal(svcPort, affinityType, 
ttlMinutes) 


return nil 


func (lb *LoadBalancerRR) newServiceInternal(svcPort 
ServicePortName, affinityType api.ServiceAffinity, 
ttlMinutes int) *balancerState { 
if ttlMinutes == 0 { 


ttlMinutes = 180 


} 
if _, exists := lb.services[svcPort]; !exists { 
lb.services[svcPort] = 
&balancerState{affinity: *newAffinityPolicy(affinityType, 
ttlMinutes)) 
glog.V(4).Infof("LoadBalancerRR service %q 
did not exist, created", svcPort) 
} else if affinityType !- "" { 
lb.services[svcPort].affinity.affinityType 
- affinityType 
} 


return lb.services[svcPort] 


我 们 在 前 面 提 到 过 ServiceConfig 同步 并 监听 API Server 上 的 
api.Service 的 数据 变化 ， 然 后 调用 Listener ( proxy.Proxier 是 
ServiceConfig 唯 一 注册 的 Listener) 的 OnUpdate 接 口 完 成 通知 。 而 上 壕 
NewService 束 是 在 proxy.Proxier 的 OnUpdate 方 法 里 被 调用 的 ， 从 而 实现 
了 Service 自 动 添加 到 LoadBalancer 的 机 制 。 


我 们 再 来 看 LoadBalancerRR 的 NextEndpoint 方 法 ， 它 实现 了 经 典 
的 round-robin 负 载 均 衡 算 法 。NextEndpoint 方 法 首先 判断 当前 服务 是 否 
有 保持 会 话 (sessionAffinity) 的 要 求 ， 如 果 有 ， 则 看 当前 请 求 是 否 有 
连接 可 用 : 


I 


if sessionAffinityEnabled { 


// Caution: don't shadow ipaddr 


var err error 
ipaddr, _, err = 
net.SplitHostPort(srcAddr.String()) 
if err != nil ( 
return "", fmt.Errorf("malformed 
source address %q: %v", srcAddr.String(), err) 
} 
sessionAffinity, exists := 
state.affinity.affinityMap[ipaddr | 
if exists && 
int(time.Now().Sub(sessionAffinity.lastUsed).Minutes()) < 
state.affinity.ttlMinutes { 
// Affinity wins. 
endpoint := 


sessionAffinity.endpoint 


sessionAffinity.lastUsed 
time.Now() 
glog.V(4).Infof("NextEndpoint for 
service %q from IP %s with  sessionAffinity %tv: 96s" 
svcPort, ipaddr, sessionAffinity, endpoint) 


return endpoint, nil 


如 果 服 务 无 须 会 话 保持 、 新 建 会 话 及 会 话 过 期 ， 则 采用 round- 
robin 算 法 得 到 下 一 个 可 用 的 服务 端口 ， 如 有 宁 服 务 有 会 话 保持 需求 ， 则 
保存 当前 的 会 话 状态 : 


// Take the next endpoint. 
endpoint := state.endpoints[state. index ] 
state.index = (state.index + 1) % 
len(state.endpoints) 
if sessionAffinityEnabled { 
var affinity *affinityState 
affinity = 
state.affinity.affinityMap[ipaddr | 
if affinity == nil { 
affinity = new(affinityState) 
//&affinityState(ipaddr, "TCP", "", endpoint, time.Now()) 
state.affinity.affinityMap[ipaddr |] 
- affinity 
} 
affinity.lastUsed = time.Now() 
affinity.endpoint = endpoint 
affinity.clientIP = ipaddr 
glog.V(4).Infof("Updated affinity key %s: 
%tv", ipaddr, state.affinity.affinityMap[ipaddr]) 
} 


return endpoint, nil 


按 下 来 我 们 看 看 Service 的 Endpoint 信 息 是 如 何 添加 到 
LoadBalancerRR 上 的 ? 答案 很 简单 ， 类 似 之 前 我 们 分 析 过 的 
ServiceConfig。kube-proxy 也 设计 了 一 个 EndpointsConfig 来 拉 取 和 监听 
API Server 上 的 服务 的 Endpoint 信 息 ， 并 调用 LoadBalancerRR 的 


OnUpdate 接 口 完成 通知 ， 在 这 个 方法 里 ，LoadBalancerRR 完 成 了 服务 
访问 端口 的 添加 和 同步 逻辑 。 


我 们 先 来 看 看 api.Endpoints 的 定义 : 


type EndpointAddress struct { 
IP string 
TargetRef *ObjectReference 

} 

type EndpointPort struct { 
Name string 
Port int 
Protocol Protocol 

} 

type EndpointSubset struct { 
Addresses []EndpointAddress 
Ports []EndpointPort 

} 

type Endpoints struct { 
TypeMeta *json:",inline"~ 
ObjectMeta '^json:"metadata, omitempty" 


Subsets []EndpointSubset 


一 个 EndpointAddress 与 EndpointPort 对 象 可 以 组 成 一 个 服务 访问 地 
址 ， 而 在 EndpointSubset 对 象 里 则 定义 了 两 个 单独 的 EndpointAddress 与 
EndpointPort 数 组 而 不 是 “服务 访问 地 址 ”的 一 个 列表 。 初 看 这 样 的 定义 


你 可 能 会 觉得 很 奇怪 ， 为 什么 没有 设计 一 个 Endpoint 结 构 ? 这 里 的 深 
层次 原因 在 于 ，Service 的 Endpoint 信 息 来 源 于 两 个 独立 的 实体 : Pod 与 
Service， 前 者 负责 提供 IP 地 址 即 EndpointAddress， 而 后 者 负责 提供 Port 
即 EndpointPort。 由 于 在 一 个 Pod 上 可 以 运行 多 个 Service ， 而 一 个 
Service 也 通常 跨越 多 个 Pod， 于 是 束 产 生 了 一 个 “ 簿 卡尔 乘积 ”的 
Endpoint 列 表 ， 这 就 是 EndpointSubset 的 设计 灵感 。 


举例 说 明 ， 对 于 如 下 表示 的 EndpointSubset: 


Addresses: [{"ip": "10.10.1.1"), {"ip": 
"10.10.2.2"}], 
Ports: [{"name": "a", "port": 8675}, {"name": 
"b", "port": 309}] 
} 


会 产生 如 下 Endpoint 列 表 : 


a: [ 10.10.1.1:8675, 10.10.2.2:8675 ], 
b: [ 10.10.1.1:309, 10.10.2.2:309 ] 
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处 理 ， 先 把 它 转 化 为 一 个 Map，Map 的 Key 是 EndpointPort 的 Name 属 性 
(代表 一 个 Service 的 访问 端口 ) ; 而 Value 则 是 hostPortPair 的 一 个 数 
组 ，hostPortPair 其 实 束 是 之 前 缺失 的 Endpoint 结 构 体 ， 包 括 一 个 IP 地 址 
与 端口 属性 ， 即 某 个 服务 在 一 个 Pod 上 的 对 应 访问 端口 。 


portsToEndpoints := map[string][]hostPortPair{} 


for 1 := range svcEndpoints.Subsets { 
ss := &svcEndpoints.Subsets[i] 
for 1 := range ss.Ports { 


port := &ss.Ports[i] 


for i := range ss.Addresses 


addr := 


&ss.Addresses[i] 


portsToEndpoints[port.Name] 三 
append(portsToEndpoints[port.Name], hostPortPair{addr.IP, 
port.Port}) 

// Ignore the 


protocol field - we'll get that from the Service objects. 


j 


下 一 步 ， 针 对 portsToEndpoints 进 行 循环 处 理 。 对 于 每 个 记录 ， 判 
靳 是 人 否 已 经 在 services 中 存在 ， 并 做 出 相应 的 更 新 或 路 过 的 逻辑 ， 最 后 
删除 那些 已 经 不 在 集合 中 的 端口 ， 完 成 整个 同步 逻辑 。 下 面 是 相关 代 
fF: 


for portname := range portsToEndpoints { 
svcPort := 


ServicePortName{types.NamespacedName{svcEndpoints.Namespace 


, svcEndpoints.Name}, portname} 


state, exists 
lb.services[svcPort] 
curEndpoints :- []string{} 


if state !- nil ( 


curEndpoints 


state.endpoints 


newEndpoints 


flattenValidEndpoints(portsToEndpoints[portname]) 


if !exists || state -- nil || 
len(curEndpoints) ! = len(newEndpoints) | | 


!slicesEquiv(slice.CopyStrings(curEndpoints), newEndpoints) 


{ 


glog.V(1).Infof("LoadBalancerRR: Setting endpoints for %s 


to %+tv", svcPort, newEndpoints) 


lb.updateAffinityMap(svcPort, newEndpoints) 

// OnUpdate can be called 
without NewService being called externally. 

// To be safe we will call 
it here. A new service will only be created 

// if one does not already 
exist. The affinity will be updated 


// later, once NewService 


is called. 
state = 
lb.newServiceInternal(svcPort, api.ServiceAffinity(""), 0) 
state.endpoints - 


slice.ShuffleStrings(newEndpoints) 


// Reset the round-robin 


index. 
state.index = 0 
} 
registeredEndpoints[svcPort] = true 
} 
} 
// Remove endpoints missing from the update. 
for k := range lb.services { 
if _, exists := registeredEndpoints[k]; 
lexists { 


glog.V(2).Infof("LoadBalancerRR: 
Removing endpoints for %s", k) 


delete(lb.services, k) 


LoadBalancerRR 的 代码 总 体 来 说 还 是 比较 简单 的 ， 它 主要 被 kube- 
proxy 中 的 关键 组 件 proxy.Proxier 所 使 用 ， 后 者 用 到 的 主要 数据 结构 为 
proxy.serviceInfo， 它 定义 和 保存 了 一 个 Service 的 代理 过 程 中 的 必要 参 
数 和 对 象 。 下 面 是 其 定义 : 


type serviceInfo struct { 


portal portal 
protocol api.Protocol 
proxyPort int 

socket proxySocket 
timeout time.Duration 
nodePort int 


loadBalancerStatus api.LoadBalancerStatus 
sessionAffinityType api.ServiceAffinity 
stickyMaxAgeMinutes int 
// Deprecated, but required for back-compat 
(including e2e) 


deprecatedPublicIPs []string 


serviceInfo 的 各 个 属性 解释 如 下 。 


portal: 用 于 存放 服务 的 Portal 地 址 ， 即 Service 的 ClusterIP (VIP) 
地 址 与 端口 。 

protcal: 服务 的 TCP， 目 前 是 TCP 与 UDP。 

socket ^ proxyPort: socket 是 Proxier 在 本 机 上 为 该 服务 打开 的 代理 
Socket; proxyPort 则 是 这 个 代理 Socket 的 监听 端口 。 

timeout: 目前 只 用 于 UDP 的 Service， 表 明 服 务 “ 链 接 ” 的 超时 时 
lia] o 

nodePort: 该 服务 定义 的 NodePort。 

loadBalancerStatus: 在 Cloud 环 境 下 ， 如 果 存 在 由 Cloud 服 务 提供 
者 提供 的 负载 均衡 器 (软件 或 硬件 ) 用 作 Kubernetes Service 的 负 
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e sessionAffinityType: 该 服务 的 负载 均衡 调度 是 否 保持 会 话 。 
e stickyMaxAgeMinutes: 即 前 面 说 的 Session 过 期 时 间 。 
e deprecatedPublicIPs: 已 过 期 、 上 废弃 的 服务 的 Public IP 地 址 。 


理解 了 serviceInfo， 我 们 再 来 看 Proxier 的 数据 结构 : 


type Proxier struct { 
loadBalancer LoadBalancer 
mu sync.Mutex // protects serviceMap 
serviceMap map [ServicePortName]*serviceInfo 
portMapMutex  sync.Mutex 
portMap map [portMapKey |ServicePortName 


numProxyLoops int32 


listenIP net.IP 
iptables iptables.Interface 
hostIP net.IP 


proxyPorts PortAllocator 


Proxier 用 一 个 Map 维 护 了 每 个 服务 的 serviceInfo 信 息 ， 同 时 为 了 快 
速 查 询 和 检测 服务 端口 是 否 有 冲突 ， 比 如 定义 了 两 个 一 样 端口 的 服 
务 ， 又 设计 了 一 个 portMap ， 其 Key 为 服务 的 端口 信息 (portMapKey 由 
port 和 protocol 组 合 而 成 ) ，value 为 ServicePortName。 了 Proxier 的 listenIP 
为 Proxier 监 听 的 本 节点 卫 ， 它 在 这 个 耻 上 接收 请 求 并 做 转发 代理 。 由 
于 每 个 服务 的 proxySocket 在 本 节点 监 昕 的 Port 端 口 默认 是 系统 随机 分 
配 的 ， 所 以 使 用 PortAllocator 来 分 配 这 个 端口 。 另 外 ，S$ervice 的 Portal 


与 NodePort 是 通过 Linux 防 火 墙 机 制 来 实现 的 ， 因 此 这 里 引用 了 Iptables 
的 组 件 完 成 相关 操作 。 
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Kubernetes 中 Service 访 问 的 一 些 网 络 细 广 。 先 来 看 看 图 6.9， 这 是 一 个 
外 部 应 用 通过 NodePort (TCP: //NodeIP: NodePort) 来 访问 Service 时 
的 网 络 流量 示意 图 。 访 问 流量 进入 节点 网 卡 eth0 后 ， 到 达 Iptables 的 
PREROUTING 链 ， 通 过 KUBE-NODEPORT-CONTAINER 这 个 NAT 规 
则 被 转发 到 kube-proxy 进 程 上 该 Service 对 应 的 Proxy 端 口 ， 然 后 由 kube- 
proxy 进 程 进行 负载 均衡 并 且 将 流量 转发 到 Service 所 在 Container 的 本 地 
端口 。 


public Client 


TCP: //NodeIP:NodePort 


Switch 


PREROUTING 


OUTPUT um 


iptables 


Kube-proxy 


图 6.9 ”外 部 应 用 通过 NodePort 访 问 Service 的 网 络 流量 示 


根据 Iptables 的 机 制 ， 本 地 进程 发 起 的 流量 会 经 过 Iptables 的 
OUTPUT 链 ， 于 是 kube-proxy 在 这 里 也 增加 了 相同 作用 的 NAT 规 则 : 
KUBE-NODEPORT-HOST ° 这样 一 来 ， 如 果 本 地 容 絮 内 的 进程 以 
NodePort 方 式 来 访问 Service， 则 流量 也 会 被 转发 到 kube-proxy 上 ， 虽 然 
以 这 种 方式 访问 的 情况 比较 少见 。 


服务 之 间 通 过 Service Portal 方 式 访问 的 流量 转发 机 制 跟 NodePort 方 
式 在 本 质 上 是 一 样 的 ， 也 是 通过 NAT， 如 图 6.10 所 示 。 当 Service A 用 
Service B 的 Portal 地 址 去 访问 时 ,流量 经 过 Iptables 的 OUTPUT 链 经 NAT 
规则 KUBE-PORTALS-HOST 的 转换 被 转发 到 kube-proxy 上 ， 然 后 被 转 
发 给 Service B 所 在 的 容器 。 


docker0 


图 6.10 Service Portal 方 式 访问 Service 的 流量 示意 


Proxier 在 创建 Iptables 的 PREROUTING 链 中 的 NAT 转 发 规则 时 ， 有 
一 些 特殊 性 ， 源 码 作者 在 代码 中 做 了 如 下 注释 ; 


“这 是 一 个 复杂 的 问题 。 


如 果 Proxy 的 ProxierlistenIP 设 置 为 0.0.0.0， 即 绑 定 到 所 有 端口 上 ， 
那么 我 们 采用 REDIRECT 这 种 方式 进行 流量 转发 ， 因 为 这 种 情况 下 ， 
返回 的 流量 与 进入 的 流量 使 用 同一 个 网 络 端口 ， 这 就 满足 了 NAT 的 规 
则 。 其 他 情况 则 采用 DNAT 转 发 流量 ， 但 DNAT 到 127.0.0.1 时 ， 流 量 会 
消失 ， 这 似乎 是 Iptables 的 一 个 众所周知 的 问题 ， 所 以 这 里 不 允许 
Proxy% E £l|localhost E. ° ” 


现在 再 看 下 面 这 段 代 码 就 容易 理解 了 ， 用 来 生成 KUBE- 
NODEPORT-CONTAINER 这 条 NAT 规 则 : 


func (proxier *Proxier ) 
iptablesContainerNodePortArgs(nodePort int, protocol 
api.Protocol, proxyIP  net.IP, proxyPort int, service 
ServicePortName) []string { 
args :- iptablesCommonPortalArgs(nil, nodePort, 
protocol, service) 


if proxyIP.Equal(zeroIPv4) | 


proxyIP.Equal(zeroIPv6) { 
// TODO: Can we REDIRECT with IPv6 
args = append(args, "-j", "REDIRECT", "-- 
to-ports", fmt.Sprintf("%d", proxyPort) ) 
) else ( 
// TODO: Can we DNAT with IPv6 


args = append(args, "-j", "DNAT", "--to- 
destination", net. JoinHostPort(proxyIP.String(), 
strconv.Itoa(proxyPort ) ) ) 


j 


return args 


弄 明 白 Proxier 中 关于 Iptables 的 事情 之 后 ， 我 们 来 研究 分 析 下 
Proxier 如 何在 OnUpdate 方 法 里 为 每 个 Service 建 立 起 对 应 的 Proxy 并 完成 
同步 工作 。 首 先 ， 在 OnUpdate 方 法 里 创建 一 个 map (activeServices) 
来 标识 当前 所 有 alive 的 Service ， key 为 ServicePortName ， 然 后 对 
OnUpdate 参 数 里 的 Service 数 组 进行 循环 ， 判 断 每 个 Service 是 否 需 要 进 
行 新 建 、 变 更 或 者 删除 操作 ， 对 于 需要 新 建 或 者 变更 的 Service， 先 用 
PortAllocator 获取 一 个 新 的 未 用 的 本 地 代理 端口 ， 然 后 调用 
addServiceOnPort 方 法 创建 一 个 ProxySocket 用 于 实现 此 服务 的 代理 ， 接 
着 调用 openPortal 方 法 添加 iptables 里 的 NAT 映 射 规则 ， 最 后 调用 
LoadBalancer 的 NewService 方 法 把 该 服务 添加 到 负载 均衡 右上 。 
OnUpdate 方 法 的 最 后 一 段 逻辑 是 处 理 已 经 被 删除 的 Service， 对 于 每 个 
要 被 删除 的 Service， 先 删除 Iptables 中 相关 的 NAT 规 则 ， 然 后 关闭 对 应 
的 proxySocket， 最 后 释放 ProxySocket 占 用 的 监听 端口 并 将 该 端口 “还 
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从 上 面 的 分 析 中 ， 我 们 看 到 addServiceOnPort 是 Proxier 的 核心 方法 
之 一 。 下 面 是 该 方法 的 源码 : 


func (proxier *Proxier) addServiceOnPort(service 


ServicePortName, protocol  api.Protocol, proxyPort int, 


timeout time.Duration) (*serviceInfo, error) { 
sock, err := newProxySocket(protocol, 
proxier.listenIP, proxyPort) 
if err != nil { 


return nil, err 


acy portStr, err = 
net.SplitHostPort(sock.Addr().String()) 
if err != nil { 
sock.Close() 


return nil, err 


} 
portNum, err := strconv.Atoi(portStr) 
if err != nil { 
sock.Close() 
return nil, err 
} 
Si :- &serviceInfo( 
proxyPort: portNum, 
protocol: protocol, 
socket: sock, 
timeout: timeout, 
sessionAffinityType: api.ServiceAffinityNone, 
// default 


stickyMaxAgeMinutes: 180, 


// TODO: paramaterize this in the API. 
} 


proxier.setServiceInfo(service, si) 


glog.V(2).Infof("Proxying for service %q on 96s 
port %d", service, protocol, portNum) 


o func(service ServicePortName roxier *Proxier 
, 


defer util.HandleCrash() 
atomic.AddInt32(&proxier.numProxyLoops, 1) 
sock.ProxyLoop(service, si, proxier) 
atomic.AddInt32(&proxier.numProxyLoops, -1) 


(service, proxier) 


return si, nil 


在 上 述 代 码 中 ， 先 创建 一 个 ProxySocket ， 然 后 创建 一 个 
serviceInfo 并 添加 到 Proxier 的 serviceMap 中 ， 最 后 局 动 一 个 协 程 调用 
ProxySocket 的 ProxyLoop 方 法 ， 使 得 ProxySocketj 进 入 Listen 状 态 ， 开 始 
接收 并 转发 客户 端 请 求 。 


kube-proxy 中 的 ProxySocket 有 两 个 实现 ， 其 中 一 个 是 
tcpProxySocket ， 另 外 一 个 是 udpProxySocket ， 二 者 的 工作 原理 都 一 
样 ， 它 们 的 工作 流程 就 是 为 每 个 客户 端 Socket 请 求 创建 一 个 到 Service 
的 后 端 Socket 和 连接 ， 并 且 “ 打 通 ” 这 两 个 Socket， 即 把 客户 端 Socket 发 来 
的 数据 “复制 * 到 对 应 的 后 端 Socket 上， 然后 把 后 端 Socket 上 服务 响应 的 
数据 写 入 客户 端 Socket 上 去 。 


以 tcpProxySocket 为 例 ， 我 们 移 看 看 它 是 如 何 完 成 Service 后 端 连 接 
创建 过 程 的 : 


func tryConnect(service ServicePortName, srcAddr 
net.Addr, protocol string, proxier *Proxier) (out net.Conn, 
err error) { 
for _, retryTimeout := range endpointDialTimeout { 
endpoint, err := 
proxier.loadBalancer.NextEndpoint(service, srcAddr) 
if err != nil { 
glog.Errorf("Couldn't find an 
endpoint for %s: %v", Service, err) 


return nil, err 


glog.V(3).Infof("Mapped service %q to 
endpoint %s", service, endpoint) 
outConn, err :- net.DialTimeout(protocol, 
endpoint, retryTimeout*time.Second) 
if err != nil { 
if isTooManyFDsError(err) { 
panic("Dial failed: " + 
err.Error()) 
} 
glog.Errorf("Dial failed: %v", err) 
continue 


J 


return outConn, nil 


return nil, fmt.Errorf("failed to connect to an 
endpoint." ) 


j 


在 上 述 方 法 里 ， 首 先 调 用 loadBalancerNextEndpoint 方 法 获取 服务 
的 下 一 个 可 用 Endpoint 地 址 ， 然 后 调用 标准 网 络 库 中 的 方法 建立 到 此 
地 址 的 连接 ， 如 果 连 接 失 败 ， 则 会 重新 尝试 ， 间 隔 时 间 指 数 增 加 C 
见 endpointDialTimeout 的 值 ) 。 


在 后 端 Service 的 连接 建立 以 后 ，proxyTCP 方 法 就 会 司 动 两 个 协 
程 ， 通 过 调用 Go 标准 库 io 里 的 Copy 方 法 把 输入 流 的 数据 写 入 输出 流 ， 
从 而 完成 前 后 端 连接 的 数据 转发 功能 。 此 外 ，proxyTCP 方 法 会 阻塞 ， 
直到 前 后 端 两 个 连接 的 数据 流 都 关闭 〈 或 结束 ) 才 会 返回 。 下 面 是 其 
源码 : 


func proxyTCP(in, out *net.TCPConn) { 
var wg sync.WaitGroup 
wg .Add(2) 
glog.V(4).Infof("Creating proxy between %v <-> %v 
<-> %V <-> %v", 
in.RemoteAddr(), in.LocalAddr(), 
out.LocalAddr(), out.RemoteAddr()) 
go copyBytes("from backend", in, out, &wg) 
go copyBytes("to backend", out, in, &wg) 
wg .Wait() 


in.Close() 


out.Close() 


这 里 我 们 留 一 个 问题 ，kube-proxy 会 在 当前 节点 上 为 每 个 Service 
都 建立 一 个 代理 么 ? 不 管 本 节点 上 是 否 有 该 Service 对 应 的 Pod? 


6.6.3 ”设计 总 结 


从 之 前 的 局 动 流程 和 代码 分 析 来 看 ，kube-proxy 的 设计 和 实现 还 
是 比较 精巧 和 紧 竣 的 ， 它 的 流程 只 有 一 个 : 从 Kubernetes API Server E 
同步 Service 及 其 Endpoint 信 息 ， 为 每 个 Service 建 立 一 个 本 地 代理 以 完 
成 具备 负载 均衡 能 力 的 服务 转发 功能 。 图 6.11 给 出 了 kube-proxy 的 总 体 
设计 示意 图 ， 为 了 清晰 地 表明 整个 业务 流程 和 数据 传递 方向 ， 这 里 省 
去 了 一 些 非 关键 的 结构 体 和 对 象 。app.ProxyServer 创 建 了 一 个 
config.SourceAPI 的 结构 体 ， 用 于 拉 取 Kubernetes API Server 上 的 Service 
与 Endpoint At 置信 Æ ， 分 别 由 config.servicesReflector 与 
config.endpointsReflector 这 两 个 对 象 来 实现 ， 它 们 各 目 通 过 相应 的 
Kubernetes Client API 来 拉 取 数据 并 且 生 成 对 应 的 Update 信 息 放 入 
Channel 中 ， 最 终 Channel 中 B5 Service Zi $ #1) iX proxy.Proxier 上 , 
proxy.Proxier 7j f} ^ Service % 37 — ^ proxySocket Sz M flt 25 REH HE 
iptables 上 创建 相关 的 NAT 规 则 ， 然 后 在 LoadBalancer 组 件 上 开通 该 服 
务 的 负载 均衡 功能 ; 而 Channel 中 的 Endpoints 数 据 则 被 发 送 到 
proxy.LoadBalancerRR 组 件 ， 用 于 给 每 个 服务 建立 一 个 负载 均衡 的 状态 
机 ， 每 个 服务 用 banlancerState 结 构 体 来 保存 该 服务 可 用 的 Endpoint 地 
址 及 当前 的 会 话 状态 affinityPolicy， 对 于 需要 保存 会 话 状态 的 服务 ， 
affinityPolicy 用 一 个 Map 来 存储 每 个 客户 的 会 话 状态 affinityState 。 


&le.11 与 kubelet 总 体 相关 的 设计 示意 图 


6.7 kubectlZEFzJB R3 4 TT 


kubectl 与 之 前 的 Kubernetes 进 程 不 同 ， 它 不 是 一 个 后 台 运 行 的 守护 
进程 ， 而 是 Kubemetes 提 供 的 一 个 命令 行 工 具 (CLI) ， 它 提供 了 一 组 
命令 来 操作 Kubernetes 集 群 。 


kubectl 进 程 的 入 口 类 源码 位 置 如 下 : 


github/com/GoogleCloudPlatform/kubernetes/cmd/kubect1/kubec 
tl.go 


入 口 main () 函数 的 逻辑 很 简单 : 


func main() { 
runtime .GOMAXPROCS(runtime.NumCPU( ) ) 
cmd := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), 

os.Stdin, os.Stdout, os.Stderr) 

if err :- cmd.Execute(); err !- nil ( 

os.Exit(1) 

} 

} 


上 有 述 代 码 通过 NewKubectlCommand 方 法 创建 了 一 个 具体 的 
Command 命 令 并 调用 它 的 Execute 方 法 执行 ， 这 是 工厂 模式 结合 命令 模 


ry ApS 


式 的 一 个 经 典 设计 和 案例。 从 NewKubectlCommand 的 源码 中 可 以 看 到 
kubectl 的 CLI 命令 框架 使 用 了 GaGitHubp 开源 项目 

(https://github.com/spf13/cobra) ， 下 面 是 该 框架 中 对 Command 的 定 
X: 


type Command struct { 
Use string // The one-line usage message. 
Short string // The short description shown in the 
'help' output. 
Long string // The long message shown in the 'help 
«this-command»' output. 
Run func(cmd *Command, args []string) // Run runs 


the command. 


j 
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面 是 其 官方 网 页 给 出 的 一 个 Echo 命令 的 例子 : 


var cmdEcho = &cobra.Command{ 
Use: "echo [string to echo]", 
Short: "Echo anything to the screen", 
Long: “echo is for echoing anything back. 
Echo works a lot like print, except it has a 
child command. 
Run: func(cmd *cobra.Command, args []string) { 


fmt.Println("Print: " + strings.Join(args, 


ty 


由 于 大 多 数 kubect 的 命令 都 需要 访问 Kubernetes API Server, PF LA 
kubectl 设 计 了 一 个 类 似 命 令 的 上 下 文 环境 的 对 象 
Command 对 象 使 用 。 


util.Factory 供 


在 接 下 来 的 几 个 章节 中 ， 我 们 对 kubectl 中 的 几 个 典型 Command 的 
源码 逐一 解读 。 


kubectl create 命 令 通 过 


X 


6.7.1 kubectl create 命 令 


才 调 用 Kubernetes API Server 提 供 的 RestAPI 来 


创建 Kubernetes 资 源 对 象 ， 例 如 Pod、Service、RC 等 ， 资 源 的 描述 信息 


来 目 -f 指 定 的 文件 或 者 来 目 命令 行 的 输入 流 。 下 面 是 创建 create 命 令 的 


相关 源码 : 


func NewCmdCreate(f 


*cobra.Command { 


*cmdutil.Factory, out io.Writer) 


var filenames util.StringList 


cmd := &cobra.Command{ 
Use: "create -f FILENAME", 
Short: "Create a resource by filename or 
stdin", 
Long: create_long, 
Example: create_example, 
Run: func(cmd *cobra.Command, args 
[]string) { 
cmdutil.CheckErr(ValidateArgs(cmd, 
args) ) 
cmdutil.CheckErr(RunCreate(f, out, 
filenames) ) 
3 


usage := "Filename, directory, or URL to file to 
use to create the resource" 
kubectl.AddJsonFilenameFlag(cmd, &filenames, usage) 
cmd.MarkFlagRequired("filename") 


return cmd 


AddJsonFilenameFlag 方 法 限制 fename 参 数 (-f) 的 文件 名 后 级 只 
能 是 json、yaml 或 者 yml 中 的 一 种 ， 并 且 将 参数 值 填充 到 filenames 这 个 
Set 集 合 中 ， 随 后 被 Command 的 Run 函 数 中 的 RunCreate 方 法 所 引用 ， 后 
# LAE: kubectl create 命 令 的 核心 逻辑 所 在 。 


RunCreate 方 法 使 用 到 了 resource.Builder 对 象 ， 它 是 kubectl 中 的 一 
处 复杂 设计 ， 采 用 了 Visitor 的 设计 模式 ，kubectl 的 很 多 命令 都 用 到 了 
它 。Builder 的 目标 是 根据 命令 行 输入 的 资源 相关 的 参数 ， 创 建 针 对 性 
的 Visitor 对 象 来 获取 对 应 的 和 资源， 最 后 过 历 相 关 的 所 有 Visitor 对 象 ， 触 
发 用 户 指定 的 VisitorFun 回 调 函 数 来 处 理 每 个 具体 的 资源 ， 最 终 完 成 资 
源 对 象 的 业务 处 理 逻 辑 。 由 于 涉及 的 资源 参数 有 各 种 情况 ， 所 以 导致 
Builder 的 代码 很 复杂 。 以 下 是 Builder 所 能 操作 的 各 种 资源 参数 : 


通过 输入 流 提 供 有 具体 的 资源 描述 ; 

通过 本 地 文件 内 容 或 者 HTTP URL 的 输出 流 来 获取 资源 描述 ; 
文件 列表 提供 多 个 资源 描述 ; 

指定 资源 类 型 ， 通 过 查询 Kubernetes API Server 来 获取 相关 类 型 的 
资源 ; 

指定 资源 的 selector 条 件 如 cluster-service=true， 查 询 Kubernetes API 


Server 来 获取 相关 的 资源 ; 


。 指定 资源 的 namespace 来 查询 符合 条 件 的 相关 资源 


下 面 是 resource.Builder 的 定义 : 


o 


type Builder struct { 


mapper *Mapper 

errs []error 

paths []Visitor 

stream bool 

dir bool 

selector  labels.Selector 
selectAll bool 

resources []string 
namespace string 

names []string 
resourceTuples []resourceTuple 
defaultNamespace bool 
requireNamespace bool 
flatten bool 

latest bool 
requireObject bool 
singleResourceType bool 
continueOnError bool 


schema validation.Schema 


其 实 Builder 很 像 一 个 SQL 但 询 条件 的 生成 侨 ， 里 面包 括 了 各 种 “ 查 
询 ” 条 件 ， 在 指定 不 同 的 查询 条 件 时 ， 会 生成 不 同 的 Visitor 接 口 来 处 理 
这 些 查 询 条 件 ， 最 后 遇 历 所 有 Visitor ， 束 得 到 最 终 的 “得 询 结果 ”。 
Builder 返 回 的 Result 对 象 里 也 包括 Visitor 对 象 及 可 能 的 最 终 资 源 列表 等 
信息 ， 由 于 资源 查询 存在 各 种 情况 ， 所 以 Result 也 提供 了 多 种 方法 ， 
比如 还 包括 了 Watch 资 源 变 化 的 方法 。 


RunCreate 方 法 里 先 创 建 了 一 个 Builder， 设 置 各 种 必要 参数 ， 然 后 
调用 Builder 的 Do 方法 ， 返 回 一 个 Result， 代 码 如 下 : 


schema, err := f.Validator() 
mapper, typer := f.Object() 
r := resource.NewBuilder(mapper, typer, 
f.ClientMapperForCommand( )). 
Schema( schema). 


ContinueOnError(). 


NamespaceParam(cmdNamespace).DefaultNamespace(). 
FilenameParam(enforceNamespace, 
filenames...). 
Flatten(). 
Do() 


其 中 ，schema 对 象 用 来 校 验资 源 描 述 是 否 正 确 ， 比 如 有 没有 缺少 
字段 或 者 属性 的 类 型 错误 等 ，mapper 对 象 用 来 完成 从 资源 描述 信息 到 
资源 对 象 的 转换 ， 用 来 在 REST 调 用 过 程 中 完成 数据 转换 ，; 
FilenameParam 是 这 里 唯一 指定 Builder 的 资源 参数 的 方法 ， 即 把 命令 行 


传 入 的 filenames 参 数 作为 资源 参数 ，Flatten 方 法 则 告诉 Builder， 这 里 
的 资源 对 象 其 实 是 一 个 数组 ， 需 要 Builder 构 造 一 个 FlattenListVisitor 来 
遍历 Visit 数 组 中 的 每 个 资源 项 目 ;，Do 方 法 则 返回 一 个 Rest 对 象 ， 里 面 
包括 与 资源 相关 的 Visitor 对 象 。 


下 面 是 NamespaceParam 方 法 的 源码 ， 主 要 逻辑 为 调用 Builder 的 
Builder.Stdin、Builder.URL 或 Builder.Path 方 法 来 处 理 不 同类 型 的 资源 参 
数 ， 这 些 方法 会 生成 对 应 的 Visitor 对 象 并 加 入 Builder 的 Visitor 数 组 里 

(paths 属 性 ) 。 


func (b *Builder) FilenameParam(enforceNamespace bool, 


paths ...string) *Builder { 


for , s :- range paths { 
switch { 
case s == "-": 
b.Stdin() 
case  strings.Index(s, "http://") == 0 || 


strings.Index(s, "https://") -- 0: 
url, err :- url.Parse(s) 
if err != nil { 
b.errs - append(b.errs, fmt.Errorf("the URL passed to 

filename %q is not valid: %v", s, err)) 

continue 

} 

b.URL(ur1) 

default: 

b.Path(s) 


j 
j 


if enforceNamespace { 


b.RequireNamespace( ) 


j 


return b 


j 


不 管 是 标准 输入 流 、URL ， 还 是 文件 目 孙 或 者 文件 本 号 ， 这 里 处 
理 资 源 的 Visitor 都 是 StreamVisitor 这 个 实现 ( FileVisitor 与 
FileVisitorForSTDIN 是 StreamVisitor 的 一 个 Wrapper) ° F M Æ 
StreamVisitor 的 Visit 接 口 代码 : 


func (v *StreamVisitor) Visit(fn VisitorFunc) error { 


d := yaml.NewYAMLOrJSONDecoder(v.Reader, 4096) 


for ( 

ext := runtime.RawExtension{} 

if err := d.Decode(&ext); err != nil { 
if err -- io.EOF ( 

return nil 

} 
return err 

} 


ext.RawJSON = bytes.TrimSpace(ext.RawJSON) 
if len(ext.RawJSON) == © || 
bytes.Equal(ext.RawJSON, []byte("null")) { 


continue 


if err :- ValidateSchema(ext.RawJSON, 
v.Schema); err !- nil { 


return err 


info, err :- v.InfoForData(ext.RawJSON, 

v.Source) 
if err != nil { 
if v.IgnoreErrors { 
fmt.Fprintf(os.Stderr, "error: could 
not read an encoded object from %s: %v\n", v.Source, err) 
glog.V(4).Infof("Unreadable: %s" 

string(ext.RawJSON)) 


continue 
} 
return err 
} 
if err := fn(info); err != nil { 
return err 
} 


i 首先 从 输入 流 中 解析 具体 的 资源 对 象 ， 然 后 创建 
一 个 Info 结 构 体 进行 包装 (转换 后 的 资源 对 象 存 储 在 urge 性 
m), 2 nc 回调 函数 VisitorFunc， 从 而 
完成 整个 逻辑 流程 。 下 面 是 RunCreate 方 法 里 调用 Builder 的 Visit 方 法 触 


发 Visitor 执 行 时 的 源码 ， 可 以 看 到 这 里 的 VisitorFunc 所 做 的 事情 是 通过 
Rest Client 发 起 Kubernetes API 调 用 ， 把 资源 对 象 写 入 资源 注册 表 里 : 


err = r.Visit(func(info *resource.Info) error { 
data, err :二 
info.Mapping.Codec.Encode(info.Object ) 
if err != nil { 
return cmdutil.AddSourceToErr("creating", 
info.Source, err) 
} 
obj, err := resource.NewHelper(info.Client, 
info.Mapping).Create(info.Namespace, true, data) 
if err != nil { 
return cmdutil.AddSourceToErr("creating", 
info.Source, err) 
} 
COUNt++ 
info.Refresh(obj, true) 
printObjectSpecificMessage(info.Object, out) 
fmt.Fprintf(out, "%s/%s\n", 
info.Mapping.Resource, info.Name) 


return nil 


}) 


6.7.2 rolling-updatefíg & 


kubectl rolling-update 命令 负责 滚动 更 新 (升级 ) RC 
(ReplicationController) ， 下 面 是 创建 对 应 Command 的 源码 : 


func NewCmdRollingUpdate(f *cmdutil.Factory, out 
io.Writer) *cobra.Command { 
cmd := &cobra.Command{ 
Use: "rolling-update OLD CONTROLLER NAME 
( [NEW CONTROLLER NAME] -image-NEW CONTAINER IMAGE | -f 
NEW CONTROLLER SPEC)", 
// rollingupdate is deprecated. 
Aliases: []string{"rollingupdate"}, 
Short: "Perform a rolling update of the 
given ReplicationController.", 
Long: rollingUpdate long, 
Example: rollingUpdate example, 
Run: func(cmd *cobra.Command, args 
[]string) { 
err :- RunRollingUpdate(f, out, 
cmd, args) 
cmdutil.CheckErr(err) 


ty 


cmd.Flags().String("update-period", updatePeriod, 
"Time to wait between updating pods. Valid time units are 


"ns", "us" (or "Hs"), "ms", “s", "m", TN T) 
此 处 省 去 一 些 命令 参数 添加 的 非 关 键 代 码 : 


cmdutil.AddPrinterFlags(cmd) 


return cmd 
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RunRollingUpdate， 在 分 析 这 个 函数 之 前 ， 我 们 先 了 解 下 rolling-update 
执行 过 程 中 的 一 个 关键 逻辑 。 


rolling update 动 作 可 能 由 于 网 络 超时 或 者 用 户 等 得 不 耐烦 等 原 
被 中 断 ， 因 此 我 们 可 能 会 重复 执行 一 条 rolling-update 命 令 ， 目 的 只 
一 个 ， 就 是 恢复 之 前 的 rolling update 动 作 。 为 了 实现 这 个 目的 ， 
rolling-update 程 序 在 执行 过 程 中 会 在 当前 rolling-update 的 RC 上 增加 一 
个 Annotation 标 签 一 kubectl.kubernetes.io/next-controller-id， 标 签 的 值 
束 是 下 一 个 要 执行 的 新 RC 的 名 字 。 此 外 ， 对 于 Image 升 级 这 种 更 新 方 
式 ， 还 会 在 RC 的 Selector 上 ( RC.Spec.Selector ) 贴 一 个 名 为 
deploymentKey 的 Label，Label 的 值 是 RC 的 内 容 进行 Hash 计 算 后 的 值 ， 
相当 于 签名 ， 这 样 就 能 很 方便 地 比较 RC 里 的 Image 名 字 (以 及 其 他 信 
fa) 是 否 发 生 了 变化 。 


RunRollingUpdate1A 41737 8 HJ 28 127 :. 确定 New RC 对 象 及 建立 起 
Old RC 到 New RC 的 关联 关系 。 下 面 我 们 以 指定 的 Image 参 数 进行 


rolling update 的 方式 为 例 ， 看 看 代码 是 如 何 实现 这 段 逻 辑 的 。 下 面 是 
相关 源码 : 


if len(image) != 0 { 
keepOldName = len(args) == 
newName := findNewName(args, oldRc) 
if | newRc, err = 
kubectl.LoadExistingNextReplicationController(client, 
cmdNamespace, newName); err !- nil { 
return err 
} 
if newRc != nil { 
fmt.Fprintf(out, "Found existing 
update in progress (%S), resuming.\n", newRc.Name) 
) else { 
newRc, err = 
kubectl.CreateNewControllerFromCurrentController(client, 
cmdNamespace, oldName, newName, image, deploymentKey) 
if err != nil { 


return err 


// Update the existing replication 
controller with pointers to the 'next' controller 
// and adding the <deploymentKey> label if 
necessary to distinguish it from the 'next' controller. 


oldHash, err := api.HashObject(oldRc, 


client .Codec) 
if err != nil { 


return err 


oldRc, err = 
kubectl.UpdateExistingReplicationController(client, oldRc, 
cmdNamespace, newRc.Name, deploymentKey, oldHash, out) 
if err != nil { 


return err 


在 代码 里 ，findNewName 方 法 查询 新 RC 的 名 字 ， 如 果 在 命令 行 参 
数 中 没有 提供 新 RC 的 名 字 ， 则 从 Old RC 中 根据 
kubectl.kubernetes.io/next-controller-idiX ^ Annotation b 2 FK Tt RCH 44 
字 并 返回 ， 如 果 新 RC 存在 则 继续 使 用 ， cu Uu) A 
CreateNewControllerFromCurrentController 方 法 创建 一 个 新 RC， 在 新 
RC 的 创建 过 程 中 设 定 deploymentKey 的 值 为 自己 的 Hash 签 名 ， 方 法 源 
码 如 下 : 


func  CreateNewControllerFromCurrentController(c 
*client.Client, namespace, oldName, newName, image, 
deploymentKey string) (*api.ReplicationController, error) ( 
// load the old RC into the "new" RC 
newRc, err = 
c.ReplicationControllers(namespace).Get(oldName) 


if err != nil ( 


return nil, err 
} 
if len(newRc.Spec.Template.Spec.Containers) > 1 { 
// TODO: support multi-container image 
update. 
return nil, goerrors.New("Image update is not 
supported for multi-container pods") 
} 
if len(newRc.Spec.Template.Spec.Containers) == 0 { 
return nil, goerrors.New(fmt.Sprintf("Pod 


has no containers! (%v)", newRc)) 


} 
newRc.Spec.Template.Spec.Containers[0].Image = 
image 
newHash, err := api.HashObject(newRc, c.Codec) 
if err != nil { 
return nil, err 
} 
if len(newName) == © { 
newName = fmt.Sprintf("96s-96s", newRc.Name, 
newHash ) 
} 


newRc.Name = newName 

newRc.Spec.Selector[deploymentKey] = newHash 

newRc.Spec.Template.Labels[deploymentKey] = newHash 
// Clear resource version after hashing so that 


identical updates get different hashes. 


newRc.ResourceVersion = "" 


return newRc, nil 


在 Image rolling update 的 流程 中 确定 新 的 RC 以 后 ， 调 用 
UpdateExistingReplicationController J 法 ， 将 IA RC 的 
kubectl.kubernetes.iommext-controller-id 设 置 为 新 RC 的 名 字 ， 并 且 判 断 旧 
RC 是 否 需要 设置 或 更 新 deploymentKey， 上 有 具体 代码 如 下 : 


func UpdateExistingReplicationController(c 
client.Interface, oldRc *api.ReplicationController, 
namespace, newName, deploymentKey, deploymentValue string, 
out io.Writer) (*api.ReplicationController, error) { 


SetNextControllerAnnotation(oldRc, newName) 


if , found := oldRc.Spec.Selector[deploymentKey]; 

! found { 
return 
AddDeploymentKeyToReplicationController(oldRc, Cy 


deploymentKey, deploymentValue, namespace, out) 
) else { 
// If we didn't need to update the controller for 
the deployment key, we still need to write 
// the "next" controller. 
return 


c.ReplicationControllers(namespace).Update(oldRc) 


j 
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建立 好 了 ， 接 下 来 如 果 dry-run 参 数 为 tue， 则 仅仅 打印 新 旧 RC 的 信息 
然后 返回 。 如 果 是 正常 的 rolling update 动 作 ， 则 创建 一 个 
kubectl.RollingUpdater 对 象 来 执行 具体 任务 ， 任 务 的 参数 则 放 在 
kubectl.RollingUpdaterConfig 中 ， 相 关 源 码 如 下 : 


updateCleanupPolicy = 
kubectl.DeleteRollingUpdateCleanupPolicy 
if keepOldName { 
updateCleanupPolicy = 
kubectl.RenameRollingUpdateCleanupPolicy 


} 
config := &kubectl.RollingUpdaterConfig{ 


Out: out, 
OldRc: oldRc, 
NewRc: newRc, 


UpdatePeriod: period, 
Interval: interval, 
Timeout: timeout, 


CleanupPolicy: updateCleanupPolicy, 


其 中 out 是 输出 流 (屏幕 输出 ) ; UpdatePeriod 是 执行 rolling update 
动作 的 间隔 时 间 ; Interval 与 Timeout 组 合 使 用 ， 前 者 是 每 次 拉 取 polling 
controller 状 态 的 间隔 时 间 ， 而 后 者 则 是 对 应 的 (HTTP REST 调 用 ) 超 
时 时 间 。 CleanupPolicy 确 定 升 级 结束 后 的 善后 策略 ， 比 如 
DeleteRollingUpdateCleanupPolicy # zs Mt) BR IH AY RC, 而 


RenameRollingUpdateCleanupPolicy 则 表示 保持 RC 的 名 字 不 变 (改变 新 
RC 的 名 字 ) 。 


RollingUpdater 的 Update 方 法 是 rolling update 的 核心 ， 它 以 上 壕 
config 对 象 作 为 参数 ， 其 核心 流程 是 每 次 让 新 RC 的 Pod 副 本 数量 加 1， 
同时 旧 RC 的 Pod 副 本 数量 减 1， 直 到 新 RC 的 Pod 副 本 数量 达到 预期 值 同 
时 旧 RC 的 Pod 副 本 数量 变 为 零 为 止 ， 在 这 个 过 程 中 由 于 新 旧 RC 的 Pod 
副本 数量 一 直 在 变动 ， 所 以 需要 一 个 地 方 记录 最 初 不 变 的 那个 Pod 副 
本 数量， 这 里 就 是 RC 的 Annotation 标签 一 一 


kubectl.kubernetes.io/desired-replicas ° 


下 面 这 段 源 码 殉 是 “贴标签 ?的 过 程 : 


fmt.Fprintf(out, "Creating %s\n", newName) 
if newRc.ObjectMeta.Annotations == nil { 


newRc.ObjectMeta.Annotations 


map[string]string{} 
} 


newRc.ObjectMeta.Annotations[desiredReplicasAnnotation] 


fmt.Sprintf("%d", desired) 


newRc.ObjectMeta.Annotations[sourceldAnnotation] = sourceId 


newRc.Spec.Replicas - 0 


r.c.CreateReplicationController(r.ns, n 


下 面 这 段 源 码 便 十 “江山 代 有 才 人 出 ， 一 代 新 人 换 旧 人 ”的 生动 画 


for newRc.Spec.Replicas < desired  && 
oldRc.Spec.Replicas != 0 ( 
newRc.Spec.Replicas += 1 
oldRc.Spec.Replicas -- 
fmt.Printf("At beginning of loop: %s 
replicas: 96d, 96s replicas: %d\n", 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas) 
fmt.Fprintf(out, "Updating %s replicas: %d, 
%S replicas: %d\n", 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas ) 
newRc, err = r.scaleAndWait(newRc, retry, 
waitForReplicas) 
if err != nil { 
return err 
} 
time.Sleep(updatePeriod) 
oldRc, err = r.scaleAndWait(oldRc, retry, 
waitForReplicas) 
if err != nil ( 


return err 


fmt.Printf("At end of loop: %s replicas: 


96d, 96s replicas: %d\n", 
oldName, oldRc.Spec.Replicas, 
newName, newRc.Spec.Replicas ) 
} 
// delete remaining replicas on oldRc 
if oldRc.Spec.Replicas != 0 { 


fmt.Fprintf(out, "Stopping %s replicas: %d 


-> %d\n", 
oldName, oldRc.Spec.Replicas, 0) 
oldRc.Spec.Replicas = 0 
oldRc, err = r.scaleAndWait(oldRc, retry, 
waitForReplicas) 
if err != nil { 
return err 
} 
} 


// add remaining replicas on newRc 
if newRc.Spec.Replicas != desired { 


fmt.Fprintf(out, "Scaling %s replicas: %d - 


> %d\n", 
newName, newRc.Spec.Replicas, 
desired) 
newRc.Spec.Replicas = desired 
newRc, err = r.scaleAndWait(newRc, retry, 
waitForReplicas) 


if err != nil { 


return err 


上 wt 7; Æ 里 的 scaleAndWait 7; 法 Va 用 T 
kubectl.ReplicationControllerScaler J Scale 777%, Scale Ù 1; 5038 1: Rest 
API 调 用 Kubernetes API Server E #tRCHYPodal AM , Aa dB ESTER 
RC 信息 ， 直 到 超时 或 者 RC 同步 状态 完成 。 下 面 是 判断 RC 同步 状态 是 

否 完成 的 函数 ， 来 自 client 包 (pkg/client/conditions.go) ° 


func ControllerHasDesiredReplicas(c Interface, 
controller *api.ReplicationController) wait.ConditionFunc { 
desiredGeneration := controller.Generation 
return func() (bool, error) { 
ctrl, err = 


c.ReplicationControllers(controller.Namespace).Get(controll 


er.Name) 
if err != nil { 
return false, err 
} 
return ctrl.Status.ObservedGeneration >= 
desiredGeneration && ctrl.Status.Replicas == 


ctrl.Spec.Replicas, nil 


J 


rolling-update 是 kubectt 所 有 命令 中 最 为 复杂 的 一 个 ， 从 它 的 功能 
和 流程 来 看 ， 完 全 可 以 被 当 作 一 个 Job 并 放 到 muc 


KM, ERU MM AC EE Job AY 81 E Job TA AS BAS AS BU AT, RR 
Kubernetes hR ECARE, 3X4 AH DARE ° 


后 记 


Kubemetes 无 疑 是 容 絮 化 技术 时 代 最 好 的 分 布 式 系统 架构 ， 但 是 
目前 它 还 没有 一 款 很 好 的 图 形 化 管理 工具 ， 基 本 上 有 是 命令 行 操 作 ， 
此 不 容易 入 门 。 另 外 ， 在 系统 运行 过 程 中 ， 我 们 难以 直观 了 解 当前 服 
务 的 分 布 情况 及 将 源 的 使 用 情况 ， 日 志 也 不 完善 ， 难 以 快速 妃 踪 和 排 
查 故 障 ， 因 此 ， 我 们 发 起 了 一 个 名 为 Ku8eye 的 开源 项 目 ， 这 是 借鉴 了 
OpenStack Horizon ` Cloudera Manager 等 知名 软件 的 设计 思想 的 一 款 国 
产 开源 软件 ， 目 标 是 成 为 Kubernetes 的 姊妹 开源 项 目 。 


Ku8eye 作 为 Kubernetes 的 一 站 式 管 理工 具 ， 具 备 如 下 关键 特性 。 


图 形 化 一 键 安装 和 部 署 多 和 点 Kubernetes 集 群 。 这 是 安装 、 部 署 
谷歌 Kubernetes 集 群 的 最 快 、 最 佳 方式 ， 其 安装 流程 会 参考 当前 
的 系统 环境 ， 提 供 默 认 优 化 的 集群 安装 参数 ， 实 现 最 佳 部 署 。 
支持 多 角色 、 多 租户 的 Portal 管 理 界面 。 通 过 一 个 集中 化 的 Portal 
界面 ， 运 党团 队 可 以 很 方便 地 调整 集群 配置 及 管理 集群 资源 ， 实 
现 跨 部 门 的 角色 、 用 户 及 多 租户 管理 ， 通 过 自助 服务 可 以 很 容易 
完成 Kubernetes 集 群 的 运 维 管 理工 作 。 

制定 了 Kubemetes 应 用 的 程序 发 布 包 标准 (ku8package) ， 并 提供 
了 一 款 回 导 工 具 ， 使 得 专门 为 Kubernetes 设 计 的 应 用 能 够 很 容易 
地 从 本 地 环境 发 布 到 公有 云 和 其 他 环境 中 ; 并 且 提 供 了 


Kubernetes 应 用 的 可 视 化 构建 工具 ， 实 现 了 Kubernetes Service ^ 
RC、Pod 及 其 他 资源 的 可 视 化 构建 和 管理 功能 。 

可 定制 化 的 监控 和 告警 系统 。Ku8eye 内 建 了 很 多 系统 健康 检查 工 
有 具 来 检测 、 发 现 异 党 并 触发 告警 事件 ， 不 仅 可 以 监控 集群 中 的 所 
有 市 点 和 组 件 (包括 Docker 与 Kubernetes) ， 还 可 以 很 容易 地 监控 
业务 应 用 的 性 能 ;， 并且 提 供 了 一 个 强大 的 Dashboard， 用 来 生成 各 
种 复杂 的 监控 图 表 以 展示 历史 信息 ， 还 可 用 来 自 定 义 相 关 监 控 指 
TAB E FIBI E? 

具备 综合 的 全 面 的 故障 排查 能 力 。Ku8eye 提 供 了 集中 化 的 唯一 日 
志 管 理工 具 ， 日 志 系 统 从 集群 中 的 各 个 市 点 拉 取 日 志 并 做 聚合 分 
析 ， 拉 取 的 日 志 包 括 系 统 日 志和 用 户 程序 日 志 ; 并 且 提 供 了 全 文 
检索 能 力 以 方便 故障 分 析 和 问题 排查 ， 检 索 的 信息 包括 相关 告警 
言 妃 ， 而 历史 视图 和 相关 的 度量 数据 则 告诉 我 们 什么 时 候 发 生 了 
什么 事情 ， 有 助 于 快速 了 解 相 关 时 间 内 系统 的 行为 特征 。 

实现 了 Docker 与 Kubernetes 项 目的 持续 集成 功能 。Ku8eye 提 供 了 
一 球 可 视 化 工具 ， 用 来 驱动 持续 集成 的 整个 流程 ， 包 括 创 建新 的 
Docker 镜 像 ，Push 镜 像 到 私有 仓库 ， 创 建 Kubernetes 测 试 环境 进行 
测试 ， 以 及 最 终 滚 动 升 级 到 生产 环境 中 的 各 个 主要 环节 。 


Ku8eye 的 GitHub 地 址 为 https:Wgithub.com/bestcloud ，Ku8eye 目 前 
所 用 到 的 技术 包括 Java Web、Ansible 脚 本 ， 未 来 可 能 涉及 Python 脚本 
及 Android 开 发 等 。 和 截至 本 书 出 版 时 ，Ku8eye 已 有 10 多 名 团队 成 员 。 如 
果 您 有 兴趣 ， 可 在 学 完 本 书后 加 入 本 项 目 QQ 群 (Kubernetes 中 国 ) : 
285431657 ° 


Invite someone 请 您 加 入 我 们 


